Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: dmoore on February 11, 2009, 02:40:49 am
-
I picked up a eee pc yesterday. nice piece of kit for the money. First thing I did was put an eee derivative of ubuntu (eeebuntu) and installed C::B from source. C++ compiling obviously isn't a netbook strong suit, but it gets the job done eventually.
most things worked without a hitch, except netbooks suffer from a reduced screen resolution on a small screen (1024*600, 10inch). Quite a few of the dialogs are too big for the screen and toolbars create a lot of clutter. It's easy enough to work around the too big dialog's with compiz moveable windows shortcuts, but it would be nicer if things fit on screen
Here's a list of issues
* Environment Settings dialog: ThreadSearch settings form makes the overall dialog too tall
* Editor Settings dialog too tall: General settings (could probably redistribute some of these items to other panes), CodeCompletion, wxSmith, and maybe IncrementalSearch
* Build Option Dialog, Compiler and Debugger Settings: too tall, not sure of cause
* CodeCompletion toolbar very wide and not sizeable.
-
I have the opposite problem. :)
Working on a 24'' display, it annoys me greatly that the dialogs are too small. Whenever I access compiler options, I have to scroll down the list (and you can't even use the mouse wheel for that!) for the sole reason that the dialog uses only a third of the available screen height (of which less than half is used for the option list).
Maybe we should invent something like a "large mode" and "small mode" of operation, which adjusts the default sizes to reasonable sizes (for example assuming a screen height of 600 for "small", 768 for "normal", and 1200 (or 1050) for "large").
-
yes, I agree. no point not using the screen real estate if it's there.
-
the challenge is coming up with a system that doesn't burden C::B and plugin devs
-
The only idea I come up with is to organize everything in virtual tabs. You classify a bunch of widgets enough for a small screen into a virtual tab. You use as many of those as you need to fit everything you want to show. For a small screen, each virtual tab maps to a real tab. If the screen is slightly bigger, you can show two of those virtual tabs per real tab. The bigger the screen, the more virtual tabs you can map to real ones. With a big screen you would expect to have no tabs at all, only a big window with everything in it.
My 2 euro cents.
-
interesting Ceniza... one approach to that would be much like a modern web page: every tab could be stacked one under the other with a scrollbar at right. the left panel would contain the icons as a shortcut to scroll to the relevant section. (still need some way to deal with wider displays - I guess the tabs could be stacked as a grid?)
-
interesting Ceniza... one approach to that would be much like a modern web page: every tab could be stacked one under the other with a scrollbar at right. the left panel would contain the icons as a shortcut to scroll to the relevant section. (still need some way to deal with wider displays - I guess the tabs could be stacked as a grid?)
A grid would be the way to show more than one virtual tab. Additionally, what would be the text of the virtual tab would become a quite visible label. The first implementation could just use one of those boxsizers with labels (even though they are not that "cute"). The problem with the stacked tabs and the scrollbar is that they would only be useful in height. A grid would still be needed to make use of the width.
I'll let you know if I come up with more ideas.
-
Today I stumbled over the wxScrollingDialog class: http://www.anthemion.co.uk/code.htm#scrollingdialog (http://www.anthemion.co.uk/code.htm#scrollingdialog).
It can be an alternative to fit dialogs on small screens.
I just tested it with the wxAui-branch and it works more or less out of the box.
Implementing it was quite easy (not tested with contrib-plugins or on windows).
I attach a screenshot from a 800x600 editor dialog.
It's surely not the best looking way to handle small screens, but it's much better than having parts of a dialog, that are not reachable.
[attachment deleted by admin]
-
I just tested it with the wxAui-branch and it works more or less out of the box.
Nice work Jens! Looks very good to me. How mature is wxScrollingDialog? Is it a (Julian Smart) 3rd Party addon or even already within a wx branch?
-
certainly a decent workaround. my only fear is that Thomas will now demand 2400x1600 dialogs. :D
more seriously, I'd still like to see a prototype of ceniza's proposal as well.
-
I just tested it with the wxAui-branch and it works more or less out of the box.
Nice work Jens! Looks very good to me. How mature is wxScrollingDialog? Is it a (Julian Smart) 3rd Party addon or even already within a wx branch?
I believe it's already inside wx branch in the form of wxScrolledWindow. Follow this url for more details.
http://docs.wxwidgets.org/stable/wx_wxscrolledwindow.html
-
I just tested it with the wxAui-branch and it works more or less out of the box.
Nice work Jens! Looks very good to me. How mature is wxScrollingDialog? Is it a (Julian Smart) 3rd Party addon or even already within a wx branch?
I believe it's already inside wx branch in the form of wxScrolledWindow. Follow this url for more details.
http://docs.wxwidgets.org/stable/wx_wxscrolledwindow.html
No,
But wxScrollingDialog uses wxScrolledWindow.
wxScrollingDialog is a convenience class that makes it easy to use standard dialogs with wxScrolledWindow, without having to change them all manually or to care about the screens size.
I include the readme.txt comimg with wxScrollingDialog, that describes how it works:
wxScrollingDialog
=======================================
This class turns your existing wxWidgets dialogs into scrolling dialogs,
when there isn't enough space to show all of the dialog at once. The standard
buttons remain on the screen at all times. This is especially useful for
devices such as the Eee PC which have a small screen.
To use, just derive from wxScrollingDialog. If you have dialog buttons that do
not have the standard identifiers (such as wxID_OK, wxID_CANCEL and wxID_APPLY)
then call AddButtonId multiple times with the identifiers of the buttons to be
left unscrolled.
The class works by searching first for a wxStdDialogButtonSizer, then a horizontal
wxBoxSizer containing standard buttons, and then individual standard buttons.
These sizers and/or buttons are removed from the existing sizer hierarchy and
added to the bottom of the dialog, while the rest of the hierarchy is attached
to a new wxScrolledWindow. The dialog is then laid out again, and if the dialog
is too big for the display, the scrollbars are enabled and the dialog resized to
fit the display.
In most situations, the layout will be similar to the original dialog. However,
if you wish to disable the layout changes, you can call SetAdaptationLevel with
0 before calling Show or ShowModal. You might want to do this, for example,
if you know in advance that the display is large enough.
For further discussion about adaptation to the Eee PC screen, see
http://wxwidgets.blogspot.com/2007/12/programming-for-eee-pc-with-wxwidgets.html
Julian Smart, December 2008
-
certainly a decent workaround. my only fear is that Thomas will now demand 2400x1600 dialogs. :D
more seriously, I'd still like to see a prototype of ceniza's proposal as well.
I also have a 24" screen, and it is true small dialogs do not make much sense. A 2400x1600 dialog would be nice if we could fit it in the so limited 1920x1200 resolution of a 24" screen :P
For the prototype, at least a decision about screen distribution would be necessary. The algorithm should be given the screen resolution, size of virtual tab (should be the same for all of them, or just calculate the longest width and height) and number of virtual tabs. It should try to distribute them with an aspect ratio close to the screen's, and leaving as few empty spaces as possible. A constraint would be, of course, to group into tabs when no more columns/rows can be added.
Another issue to discuss can be best described by quoting a Pink Floyd's song:
"What shall we use to fill the empty spaces?"
-
jens: patch file?
-
jens: patch file?
I patched an old wxAui-branch.
That means I have to patch the actual trunk to create a patch.
Hopefully this evening/night (it's 10pm here) or tomorrow.
-
the aui branch is probably fine (unless really old). I have a recent copy of the aui branch on my machine. no hurry though
-
I attach a 7z-file containing the patch against svn r5469 and the files scrollingdialog.cpp and scrollingdialog.h and scrollingdialog.patch.
Copy scrollingdialog.cpp to src/sdk/ and scrollingdialog.h to src/include.
Don't apply scrollingdialog.patch, it's the patch against the original scrollingdialog.*-files I used to make it useable with C::B.
Its include just for documentation purposes.
Apply scrollingdialog_20090223-1.patch.
It does not work with actual wxAui-branch, there will be some failed hunks if you try.
The patch is not (yet) tested under windows.
So it still might crash with some dialogs, I tested most of them, but most likely forgot some.
Contrib-plugins are also tested.
wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files.
That means of course that, if wxs-files are opened with wxSmith the appropriate source- and header-files will be changed, so that the standard wxDialog will be used again.
To test how it works, I reduced my actual screen-size to 768x576 (really small, normally I have 1920x1200 on my laptop).
EDIT:
On Windows don't forget to add the two new files to the project-file (both in target sdk).
[attachment deleted by admin]
-
patch applies fine but i get cc1plus segfault building ipc.cpp (encoding issue or maybe i corrupted my working copy?)
-
Do you use gcc 4.3 ?
I have the same problem (at least on 64-bit) withh gcc 4.3 when building C::B from inside C::B, never found the reason.
You can remove ipc.cpp from the project-file, it's not used.
-
the aui branch is probably fine (unless really old).
Huh? In fact it's quite up-to-date! (At last after the last merge...)
-
I attach a 7z-file containing the patch against svn r5469
Very nice work, Jens.
wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]
...although this is a serious show-stopper to me. We should really think about whether the benefits are worth that costs. For me this drawback makes it quite useless (unfortunately). I would vote for leaving it as a proof-of-concept in the patch tracker.
...or do you (all devs) seriously thinking to apply this into trunk?
-
wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]
...although this is a serious show-stopper to me. We should really think about whether the benefits are worth that costs. For me this drawback makes it quite useless (unfortunately). I would vote for leaving it as a proof-of-concept in the patch tracker.
...or do you (all devs) seriously thinking to apply this into trunk?
The xrc-files are no problem.
They get loaded as normally, and can be used as before, even if the loaded dialog is inherited from wxScrollingDialog (otherwise the most of our dialogs would fail).
I left them untouched, because the xml-loader don't know wxScrollingDialog and can not load the resources correctly.
The only real problem is with wxSmith, because it directly changes the source and headerfiles, and every change (to use wxScrollingialog) will be changed back to wxDialog.
EDIT:
it should also be possible (and that would be the cleaner way, I think) to overwork all dialogs, to use wxScrolledWindow to make the client-part scrollable.
The "main"-buttons can be left in the unscrolled-part as it is done by wxScrollingDialog.
I don't know whether wxSmith knows wxScrolledWindow, but if not it can surely be implemented.
-
I attach a 7z-file containing the patch against svn r5469
Very nice work, Jens.
wxs- and xrc-files are left originally, because otherwise the xml-loader crashes and wxSmith can no longer read the files. [...]
...although this is a serious show-stopper to me. We should really think about whether the benefits are worth that costs. For me this drawback makes it quite useless (unfortunately). I would vote for leaving it as a proof-of-concept in the patch tracker.
...or do you (all devs) seriously thinking to apply this into trunk?
one suggestion it can be used like feather
place it somewhere with one check box to set it on and off for those who want it :)
-
I would be a very nice feature.
But I am biased, because next month when I am in the USA I will most probably buy a .... netbook. And one of the first things will be building and using CB ;-)
-
place it somewhere with one check box to set it on and off for those who want it :)
It would be possible to use a switch to allow wxScrollingDialog to rearrange the dialogs.
But I don't think it is needed, because for screens that are large enough, it should not make a visible difference.
-
the aui branch is probably fine (unless really old).
Huh? In fact it's quite up-to-date! (At last after the last merge...)
i was referring to jens post where he said
I patched an old wxAui-branch.
Do you use gcc 4.3 ?
I have the same problem (at least on 64-bit) withh gcc 4.3 when building C::B from inside C::B, never found the reason.
You can remove ipc.cpp from the project-file, it's not used.
I'm using 4.3. I haven't had the problem until last night. As you suggested, I removed the file and it compiled. However, I would like to understand what broke the compiler...
Your scrolling dialog tweaks get the job done nicely. thanks!
I started hacking at a class derived from wxListbook to stack dialogs in a scrolled pane as an alternative. might take me a day or two to get working. (more from lack of time than any great complexity)
-
I think it was better for using "wxNotebook" control than "wxScrollDialog"..
-
I think it was better for using "wxNotebook" control than "wxScrollDialog"..
if you bothered to test the patch, you'll see that it still uses a notebook. the notebook itself is put inside a scrolling window, which will automatically add scrollbars if the panel is too big to fit on screen.
-
Can't we show the options panel as a cbEditor or instead of the editors? Pretty much like the "start here" page works, too.
That way, we could make use of the entire screen estate, and scrollbars would fit in neatly. This would work better both for small and large screens.
-
Can't we show the options panel as a cbEditor or instead of the editors? Pretty much like the "start here" page works, too.
That way, we could make use of the entire screen estate, and scrollbars would fit in neatly. This would work better both for small and large screens.
I agree this would be nice and more along the lines of what Ceniza and I have been thinking.
-
I think it was better for using "wxNotebook" control than "wxScrollDialog"..
if you bothered to test the patch, you'll see that it still uses a notebook. the notebook itself is put inside a scrolling window, which will automatically add scrollbars if the panel is too big to fit on screen.
OH, very good! what I meaning is :
[attachment deleted by admin]