octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Successfully merged projects


From: John Swensen
Subject: Re: Successfully merged projects
Date: Wed, 13 Apr 2011 07:55:26 -0400

On Apr 13, 2011, at 6:53 AM, Jacob Dawid wrote:

> 
> Jacob,
> It is coming together nicely.  Is there a reason that the Command Window, 
> File Editor, Documentation, and Service widgets have to be tabbed like that?  
> I usually work with my editor and command window visible at the same time.  
> Do you have any objections to having everything be in a QDockWidget so things 
> can be arranged in whatever way the user sees fit to arrange it? Also, does 
> the QDockWidget interface only allow a left, right, top, and bottom widget?  
> Is there a way to achieve being able to put dock widgets 4, 5, or 6 wide.  My 
> hope was that the QDockWidgets would allow any arrangement possible, but it 
> seems it is designed to only allow center, left, right, top, and bottom.
> 
> John Swensen
> 
> QDockWidget are only "Tool Windows" that are positioned around the central 
> widget, which is the tabbed view here. I have used the Tabs of the central 
> widget for unique subwindows, and an MDI Tab for the File Editor that 
> supports multiple documents. We can still see if it is better to rearrange 
> that, though. What's your suggestion here?
> 

I just tried calling
setDockOptions (QMainWindow::AllowNestedDocks);
in the constructor of the MainWindow class.  This allow me to place 
QDockWidgets anywhere in the window.  My original thought was to make every 
component/panel of the IDE a derivative of QDockWidget. In this manner, people 
can arrange things however they want (including separating any of the 
QDockWidgets out as its own window if they choose to).  I have included two 
links to images of my common configuration when using Matlab and one that two 
of my colleagues use quite often.  I think we can achieve the same degree of 
configurability using QDockWidget.
http://imgur.com/UvAXf
http://imgur.com/ztCQn

As to the editor component.  I also think that using QScintilla is a better 
choice for a couple of reasons.
1) unless all the QtOctave developers plan on jumping onboard Quint, and where 
QtOctave is a little more mature but still a fledgling project, I expect that 
the changes in API to their editor component will cause you more headaches than 
it is worth.  QScintilla is mature enough (especially the Scintilla side of 
things) that API changes are rare.
2) QScintilla has its own team of developers finding bugs, making improvements, 
answering mailing list questions, etc.  Any time we can get someone else to do 
a chunk of the work (and we all know that Octave and Octave derivative 
developers are in short supply), especially when that chunk of work may end up 
being the most difficult part of an Octave IDE to get "right", I think we 
should exploit it to the full extent possible.
3) From my limited investigation a couple of months ago when I was planning the 
switch from GKT to Qt and had eventually decided QScintilla was the best 
option, here is how I understand that QScintilla works. QScintilla has two 
APIs: the QT API and the Scintilla API.  Scintilla was an editor component long 
before someone ported it to Qt.  The port to Qt implements a complete QWidget 
and has much of the functionality available in a Qt-friendly way.  However, to 
access some of the functionality of Scintilla you have to make direct calls to 
the SCI_* functions. Even though this may seem strange, it allows them to pull 
bugfixes and feature enhancements from GTK and WxWindows based Scintilla 
component quite easily.


John

P.S. Jacob, sorry for the double email, but I realized I didn't reply to the 
list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]