hi,

how does one re-open the render view + Consoles widgets after they have been
closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

happened because I rendered a static scene, clicked that editor tab shut, opened
another scene, then the associated ini, chose that for rendering.  however, the
view of the previous image remained, so I clicked it shut - only not to find a
way to reopen it.

btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
and I get:

xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
per invocation.

[19:23:28.805] WARN
Unhandled PrintStatusChanged
 ((null):0)

[19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

would like to read the tutorial etc, but, probably because I'm a bit dense at
times, the "compass" feature does not work for me, which "next" button?


regards, jr.

Post a reply to this message

On 06/28/2018 03:08 PM, jr wrote:
> hi,
> 
> how does one re-open the render view + Consoles widgets after they have been
> closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

I think I can add the 'view' menu.  Currently, it is Qt magic. 
Right-click on one of the docking borders. That is, the "Resources" 
header or the "Consoles" header. It will give you a list of available 
windows to turn on and off.

> 
> btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> and I get:
> 
> xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
> xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

If you didn't install them, that's pretty much what you get.  I am going 
to dim those menu entries if they don't exist. And add a bit in the 
config dialog so you can point to wherever those directories live on 
your system.  I just added those two menus last night, having discovered 
the pretty awesome distribution/scenes directory (open that in firefox).

> 
> also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> per invocation.
> 
> [19:23:28.805] WARN
> Unhandled PrintStatusChanged
>   ((null):0)

This is debug foo. I should remove it from production.  Basically povray 
is telling me something I'm ignoring.

> 
> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

This one is interesting.  Um, what it means is um ...
I would guess maybe it's trying to draw to one of the windows you closed 
(although Qt should be filtering that).

> 
> would like to read the tutorial etc, but, probably because I'm a bit dense at
> times, the "compass" feature does not work for me, which "next" button?

Last night I copied
http://www.buckosoft.com/qtpov/
to
http://www.buckosoft.com/qtpovray/

and didn't fix the database driven navigation.  (I needed the url for 
the debian package.) Use the first one and ignore the bits about a 
separate websockets executable, and everywhere else read "qtpovray" 
where it says "qtpov".
I am going to rework that so it can be included with the package.

> 
> 
> regards, jr.

Thanks for trying it out!



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

On 06/28/2018 01:54 PM, jr wrote:
> hi,

> 
> will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
> executables named 'povrayNN*', a symlink would be not as convenient for my
> setup, the ("dead") .ini file option looks so much better.  would it be much
> work to "resurrect" it?

povray is built into qtpovray.  There is no need for a separate 
executable.  A symlink would be of no value because there is nothing to 
point to. ;)



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > how does one re-open the render view + Consoles widgets after they have been
> > closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.
>
> I think I can add the 'view' menu.  Currently, it is Qt magic.
> Right-click on one of the docking borders. That is, the "Resources"
> header or the "Consoles" header. It will give you a list of available
> windows to turn on and off.

I tried switching all except 'main' off, then there seems to be no "docking
border"s.

> > btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> If you didn't install them, that's pretty much what you get.  I am going
> to dim those menu entries if they don't exist.

yes, or (as many do) a simple "ok" type dialog with message?

> And add a bit in the
> config dialog so you can point to wherever those directories live on
> your system.

sounds good.  more flexibility.

>  I just added those two menus last night, having discovered
> the pretty awesome distribution/scenes directory (open that in firefox).

I have those too, did them for povray 3.7.

> > also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> > per invocation.
> >
> > [19:23:28.805] WARN
> > Unhandled PrintStatusChanged
> >   ((null):0)
>
> This is debug foo. I should remove it from production.  Basically povray
> is telling me something I'm ignoring.

ok.

> > [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> > resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>
> This one is interesting.  Um, what it means is um ...
> I would guess maybe it's trying to draw to one of the windows you closed
> (although Qt should be filtering that).

I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
existing .pws files).

> > would like to read the tutorial etc, but, probably because I'm a bit dense at
> > times, the "compass" feature does not work for me, which "next" button?
> Last night I copied
> http://www.buckosoft.com/qtpov/
> to
> http://www.buckosoft.com/qtpovray/
> and didn't fix the database driven navigation.  (I needed the url for
> the debian package.) Use the first one and ignore the bits about a
> separate websockets executable, and everywhere else read "qtpovray"
> where it says "qtpov".
> I am going to rework that so it can be included with the package.

cool.

> Thanks for trying it out!

soon you'll be pulling your hair out because I'll be nitpicking and flood you
with "feature requests".  :-)

speaking of which, the name of the current workspace (file) would be good to
have in the titlebar, or somewhere prominent.

(see, it's already started..  :-))


regards, jr.

Post a reply to this message

On 06/28/2018 05:50 PM, jr wrote:
> hi,

>>
>> I think I can add the 'view' menu.  Currently, it is Qt magic.
>> Right-click on one of the docking borders. That is, the "Resources"
>> header or the "Consoles" header. It will give you a list of available
>> windows to turn on and off.
> 
> I tried switching all except 'main' off, then there seems to be no "docking
> border"s.
> 

Hmm, yes I see. You're kind of screwed, eh?

The toolbar has a grabber on the left side. Try to right-click that, or 
someplace on the toolbar that's not a button.


> 
>>> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
>>> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>>
>> This one is interesting.  Um, what it means is um ...
>> I would guess maybe it's trying to draw to one of the windows you closed
>> (although Qt should be filtering that).
> 
> I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> existing .pws files).

Since this is something between Qt and X11, it would be helpful to know 
when this error^H^H warning occurred.  My X log just has a ton of 
"monitor on, monitor off".


> 
> soon you'll be pulling your hair out because I'll be nitpicking and flood you
> with "feature requests".  :-)
> 
> speaking of which, the name of the current workspace (file) would be good to
> have in the titlebar, or somewhere prominent.
> 
> (see, it's already started..  :-))

I guess I should open the github bug thingy.

> 
> 
> regards, jr.
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> >> I think I can add the 'view' menu.  Currently, it is Qt magic.
> > I tried switching all except 'main' off, then there seems to be no "docking
> > border"s.
> Hmm, yes I see. You're kind of screwed, eh?

didn't you mean "screwy"?  :-)

> The toolbar has a grabber on the left side. Try to right-click that, or
> someplace on the toolbar that's not a button.

either way, thanks, easy -- once one knows.

> >>> [19:51:01.141] WARN QXcbConnection: XCB error: ...
> >> This one is interesting.  Um, what it means is um ...
> >> I would guess maybe it's trying to draw to one of the windows you closed
> >> (although Qt should be filtering that).
> > I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> > existing .pws files).
> Since this is something between Qt and X11, it would be helpful to know
> when this error^H^H warning occurred.  My X log just has a ton of
> "monitor on, monitor off".

I understand.  will try and pay closer attention when I'll use/play with
'qtpovray'.

> > soon you'll be pulling your hair out because I'll be nitpicking and flood you
> > with "feature requests".  :-)
> >
> > speaking of which, the name of the current workspace (file) would be good to
> > have in the titlebar, or somewhere prominent.
> >
> > (see, it's already started..  :-))
>
> I guess I should open the github bug thingy.

I'll make it worth your while: whether checked or not, "large icons" is,
apparently, all that is on offer.  ;-)


regards, jr.

Post a reply to this message

I don't get git.
My last merge of povray was from master on 12/17/17.
At the time, source/base/version.h was reporting povray as version
3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"

I picked up that version number (and didn't really care).

In my head, I noticed a discrepancy when clipka suggested I call mine
v3.80.0 (why not 3.81.0 ?).

Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
most of the branches.

I just merged autobuild/alpha_v380.  In source/base/version.h I picked
up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
from 2017 to 2018.
But, I still have
#define POV_RAY_PATCHLEVEL_INT      1
instead of
#define POV_RAY_PATCHLEVEL_INT      0
which is in the merged-from file.

Why?  I have not altered this, and if I had, I should get a conflict.
If makes me nervous for whatever other files I may not have picked up
changes on.

https://github.com/dickbalaska/qtpovray/commit/f0eb4228ecfe624e905fe04367a73d3cc514f8fa#diff-456b041bdd8c9f06ec0514302ebba61b
( https://tinyurl.com/y7t5hh8x )
-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

For the records, that was not a burp. Here's what had happened:

- What is now v3.8.0 (currently in alpha phase) was originally slated to
be released as v3.7.1, and as such had already reached beta phase (and,
for a few days, even RC phase) before being rebranded as v3.8.0.

- Upon reaching beta phase, v3.7.1 was branched off `master` so that
finalization of that version could happen in a separate branch
(`release/v3.7.1`), while the master branch could continue to be used
for adding new features. At that point, the master branch was bumped to
version number v3.7.2-alpha.

- When it was decided that v3.7.1 would be too different from v3.7.0, it
was re-branded v3.8.0.

- While v3.8.0 was put back into alpha stage, it was originally expected
that the version would quickly fast-forward to RC phase again. It was
therefore left in its own branch (though now renamed `release/v3.8.0`),
while the master branch was bumped to the next version number, v3.8.1.

- When it became obvious that v3.8.0-beta wasn't going to be just a few
days ahead, all the changes in the master branch (i.e. changes
originally slated for a later version) were also merged into v3.8.0, and
that version moved back into the master branch. (Technically this was
done by simply merging v3.8.0 into the master branch.)

Post a reply to this message

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

"Most" is the keyword here.

> I just merged autobuild/alpha_v380.  In source/base/version.h I picked
> up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
> from 2017 to 2018.
> But, I still have
> #define POV_RAY_PATCHLEVEL_INT      1
> instead of
> #define POV_RAY_PATCHLEVEL_INT      0
> which is in the merged-from file.
> 
> Why?  I have not altered this, and if I had, I should get a conflict.
> If makes me nervous for whatever other files I may not have picked up
> changes on.

Unfortunately, v3.8.0-alpha.9606898 was built just /before/ the merge of
`master` and `release/v3.8.0`.

This means your version number details are determined as follows:

- The _common base_ is the last common ancestor (including merges) of
`qtpovray` and `autobuild/alpha_v380`. That would be commit bb85b4fd
dated 2017-11-18, then on the `release/v3.8.0` branch. On that commit,
the version number details were as follows:

    #define POV_RAY_MAJOR_VERSION_INT   3
    #define POV_RAY_MINOR_VERSION_INT   8
    #define POV_RAY_REVISION_INT        0
    #define POV_RAY_PATCHLEVEL_INT      0
    #define POV_RAY_PRERELEASE          "alpha"

- One line of inheritance would be via the `master` branch and then
`qtpovray`, starting with the merge commit b3038c26 dated 2017-12-03.
While this commit leaves the version number unchanged /on the master
branch/, the commit /does/ constitute a version number change with
respect to the _common base_, changing the following:

    #define POV_RAY_REVISION_INT        1

- The second line of inheritance would be via `release/v3.8.0` and then
`autobuild/alpha_v380`. The only version number changes with respect to
the _common base_ in this line of inheritance are changes of the
prerelease ID, with the last such change being the following:

    #define POV_RAY_PRERELEASE          "alpha.9606898"

So you have one line of inheritance saying POV_RAY_REVISION_INT needs to
be changed to 1, and another line of inheritance saying
POV_RAY_PRERELEASE needs to be changed from "alpha" to "alpha.9606898".

Since the changes seem to be independent, no conflict is raised, leaving
you with version number v3.8.1-alpha.9606898.

Post a reply to this message

On 07/16/2018 08:57 AM, clipka wrote:

> while the master branch was bumped to the next version number, v3.8.1.

That makes sense.  I retract 'burp'.

(I had assumed [1] you changed 3.7.1 to 3.8.0 and changed the 7 to 8 and
forgot to change 1 to 0.)


[1] When you assume ...

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message