On Mon, Mar 21, 2016 at 2:50 AM, Jasvir Singh wrote:
> It's working fine now.
> http://screencloud.net/v/528K
I have submitted a patch: https://sourceforge.net/p/brlcad/patches/437/
Please review this one.
--
Jasvir Singh Grewal
https://github.com/jasvir99
-
On Mon, Mar 21, 2016 at 4:22 AM, Clifford Yapp wrote:
> Does the red line in the lower left indicate you are doing drawing?
> If so, that's probably activating/refreshing the view.
>
I tried drawing a simple line using GL Lines.
> If I were going to suggest "first steps" for work with the Qt dis
On Mon, Mar 21, 2016 at 5:50 AM, Jasvir Singh wrote:
> On Fri, Mar 11, 2016 at 11:06 AM, Clifford Yapp wrote:
>>
>> That looks like it's just the placeholder OpenGL Qt widget not getting
>> updated - remember, there's no drawing activity going on so the canvas
>> area is not refreshing itself.
>
On Fri, Mar 11, 2016 at 11:06 AM, Clifford Yapp wrote:
>> Can anyone please help me to figure it out?
>
> That looks like it's just the placeholder OpenGL Qt widget not getting
> updated - remember, there's no drawing activity going on so the canvas
> area is not refreshing itself.
It's working f
On Fri, Mar 11, 2016 at 11:06 AM, Clifford Yapp wrote:
> http://screencloud.net/v/ori3
>>
>> Can anyone please help me to figure it out?
>
> That looks like it's just the placeholder OpenGL Qt widget not getting
> updated - remember, there's no drawing activity going on so the canvas
> area is not
On Fri, Mar 11, 2016 at 1:37 PM, Jasvir Singh wrote:
> On Thu, Mar 10, 2016 at 10:08 PM, Jasvir Singh
> wrote:
>>> Cheers!
>>> Sean
>>
>> As suggested by Clifford, previous code is working fine.
>
> Everything is working fine except that when I star qged, draw area
> opens with a screenshot of b
On Thu, Mar 10, 2016 at 10:08 PM, Jasvir Singh wrote:
>> Cheers!
>> Sean
>
> As suggested by Clifford, previous code is working fine.
Everything is working fine except that when I star qged, draw area
opens with a screenshot of background.
http://screencloud.net/v/ori3
Can anyone please help me
On Tue, Mar 8, 2016 at 2:43 PM, Christopher Sean Morrison
wrote:
> So first step is probably to get familiarized with the old code, get it up
> and running, perhaps submit a patch if changes are needed to get it working
> again.
>
> Cheers!
> Sean
As suggested by Clifford, previous code is work
On Tue, Mar 8, 2016 at 5:43 PM, Christopher Sean Morrison
wrote:
>
>> On Mar 8, 2016, at 3:58 PM, Jasvir Singh wrote:
>>
>> Further I wish to know about whether someone is working on qtged or
>> not. I am trying to understand working of MGED and I wish to
>> contribute into qtged. I'll really app
> On Mar 8, 2016, at 3:58 PM, Jasvir Singh wrote:
>
> Further I wish to know about whether someone is working on qtged or
> not. I am trying to understand working of MGED and I wish to
> contribute into qtged. I'll really appreciate if someone can help me
> to start with it.
Nobody is working o
Hi there.
I was looking into incorporating Qt with MGED and Daniel provided
information about GSoC 2013 project[0]. I asked for more information
about this on IRC and got some useful information[1].
Further I wish to know about whether someone is working on qtged or
not. I am trying to understand
2013/9/22 Vlad Bogolin :
>> PS: An idea for a fix of the segmentation fault bug: This could be
>> caused by mixing the single- and multithread mode of libX11. I.e. the
>> main window will be opened from Tk in singlethread mode. The Qt
>> switches to multithread and closing the main window will le
Hi,
As a conclusion to your GSoC project you should write down what was
> achieved and what's still open ("not implemented" functions, frame
> buffer, ...)
>
> I have made a summary wiki page of my project that can be found here:
http://brlcad.org/wiki/User:Vladbogolin/GSoC2013/qt-display-manager
Vlad,
You should make a break in searching for the reason of the
segmentation fault and polish your work a little bit before GSoC ends.
There are still some functions "not implemented". Maybe some of them
are trivial.
In qt_close() you write privars->win->~QTkMainWindow();. That's
rather unusu
Hi,
First of all thanks for the hints.
>
> > Next you could put break points where the resource is allocated
> > (NewDatabase) and destroyed (XrmDestroyDatabase). In case of the Qt
> > display manager the database resource will be destroyed without
> > creating it before. That's probable not op
2013/9/18 Daniel Roßberg :
> Next you could put break points where the resource is allocated
> (NewDatabase) and destroyed (XrmDestroyDatabase). In case of the Qt
> display manager the database resource will be destroyed without
> creating it before. That's probable not optimal.
Ups, that's not
2013/9/18 Vlad Bogolin :
>> You really need a stack trace or debugging information of some sort to go
>> on. You can also try to compile BRL-CAD as single-threaded to see if the
>> problem is specific to something Qt's doing or our parallelism. (cmake
>> -DBRLCAD_ENABLE_SMP=NO)
>>
> I've did a ba
Hi,
> Can you reproduce the segfault in the debugger?
The segfault can be reproduced in the debugger but I've managed to catch it
just when not using classic mged (without the -c option).
You really need a stack trace or debugging information of some sort to go
> on. You can also try to comp
I can reproduce the segmentation fault but I have no hint how to solve
this issue.
It looks like the function pthread_mutex_lock() is called with an
invalid (NULL) mutex. This happens deep inside libX11 called by Tk.
So my assumption was that Qt and Tk disagree on the ownership of a X11
resource.
On Sep 15, 2013, at 2:15 PM, Vlad Bogolin wrote:
> When closing the qt display manager sometimes a segfault occurs. I've seen
> that this occurs after the close function is called and gdb says the
> fallowing:
>
> Program received signal SIGSEGV, Segmentation fault.
> __GI___pthread_mutex_lock
Hi all,
When closing the qt display manager sometimes a segfault occurs. I've seen
that this occurs after the close function is called and gdb says the
fallowing:
Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
50pthread_mu
On Sep 11, 2013, at 4:16 AM, Vlad Bogolin wrote:
> I modified the code so that every time Tcl_DoOneEvent is called
> QApplication::processEvents is also called so that there aren't any
> modification to the code that have to be done besides checking for Tk events
> non-blocking. I couldn't fig
Hi,
I found another solution, actually more like a hack that simulates
non-blocking behavior. I use Tcl_DoWhenIdle to call a procedure and then
reschedule the procedure using Tcl_CreateTimerHandler but I don't think is
the best solution so I'll make a little more research. What do you think?
Do y
Vlad,
Unfortunately I won't be able to look at it before next Monday (I'm
currently not at home).
Daniel
Am 11.09.2013 10:16 schrieb "Vlad Bogolin" :
> Hi,
>
> I saw that. Can you think of a way to register your Qt event loop
>> processing without directly modifying bwish?
>>
>
> I modified the
Hi,
I saw that. Can you think of a way to register your Qt event loop
> processing without directly modifying bwish?
>
I modified the code so that every time Tcl_DoOneEvent is called
QApplication::processEvents is also called so that there aren't any
modification to the code that have to be done
On Sep 08, 2013, at 03:01 PM, Vlad Bogolin wrote:I have finished the Qt event processing in archer. Now everything should be displayed properly, but I'm not sure if I used the best approach as I had troubles finding the connection between bwish and archer so I am open to suggestions or improvement
Hi,
I have finished the Qt event processing in archer. Now everything should be
displayed properly, but I'm not sure if I used the best approach as I had
troubles finding the connection between bwish and archer so I am open to
suggestions or improvements.
Cheers,
Vlad
Hi,
The version of the Qt display manager at SourceForge still crashes
> when used in archer. What stops you from checking in your changes so
> we all could have a look at it?
>
Sorry about that. I was working in processing the events in a better way
and I forgot to commit the changes. Now, arch
Vlad,
The version of the Qt display manager at SourceForge still crashes
when used in archer. What stops you from checking in your changes so
we all could have a look at it?
Regards,
Daniel
--
Learn the latest--Visu
Mesut,
Some thought about your patch:
First of all it looks extensive as if it could work. But I couldn't
compile it because of many unused-parameter errors. There are
differences between the gcc versions. If you use a more current one
you should see these errors too.
Some smaller things:
- Th
> Gesendet: Dienstag, 05. Juni 2012 um 12:39 Uhr
> Von: "Daniel Roßberg"
> An: "BRL-CAD Developer Mailing List"
> Betreff: Re: [brlcad-devel] Qt display manager
> 2012/6/5 "Mesut Özdogan"
> >
> > Hi Daniel,
> >
> > thank y
2012/6/5 "Mesut Özdogan"
>
> Hi Daniel,
>
> thank you for your help. You're right, i have done it the wrong way. I
> wanted to add the functions step by step, which could only compiled with
> brlcad after all was finished...
I recommend to start with the task described in my mail i.e. dm-qt.c.
>
32 matches
Mail list logo
