 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] buckosoft com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
