search

Jas6666 / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

GUI position switchable vertically/horizontally? #136

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
The first feature that stroke me as lacking when using the wonder that is
GrafX2, believe it or not, is the ability to switch its display from
horizontal to vertical, and also drag it top/down screen or right/left
screen respectively.

That might really sound like a shallow fancy requirement, but I've always
found the vertically displayed toolbars in graphic editors to be more to my
liking and I believe it slightly but noticeably improve the ease to use it.

I expect I may not be the only one to feel that way, so I hope such request
(as unimportant as it might seem) will meet a positive answer from the
developers.

Original issue reported on code.google.com by benoist....@gmail.com on 6 Mar 2009 at 7:35

GoogleCodeExporter commented 8 years ago 
Hello :)
We have already talked about this in another unrelated issue report, but i 
can't 
find it back right now.
You are not the first to request that.
The problem is most of our low-level functions drawing to the screen are all 
assuming the menu is at the bottom. Changing this involves quite a lot of work 
and 
changes in all the drawing functions to check where is the menu. The amount of 
work 
is so high that no one feels very motivated to do it. And it also means we 
won't do 
that in the 2.0 release, you'll have to wait until some beta after that.

Original comment by pulkoma...@gmail.com on 6 Mar 2009 at 7:43

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Well, I'll just prove patient then... (^_-) Not that this very minor issue for 
me
would be even close to spoil my enjoying the soft anyway of course.

Way to go for such an amazing tool guys!

Original comment by benoist....@gmail.com on 6 Mar 2009 at 7:48

GoogleCodeExporter commented 8 years ago 
The  "status bar" with the current file name, coordinates, etc. still has to be
horizontal, even if the toolbar is vertical.
The minimum screen height becomes about 330 pixels.

Original comment by yrizoud on 6 Mar 2009 at 9:30

GoogleCodeExporter commented 8 years ago 
Filename/coords and stuff could be displayed out of the main GUI, like in a 
menubar
(well, DPaint way exactly... :-P), but I willingly aknowledge that, as 
Pulkomandy
noted above, this would turn things more into a major revamping the GUI, way 
too much
work compared to the small benefit of it perhaps...

(And still, I can't help but maintain that I miss the freely positionable GUI a 
bit!!
(^_^)b)

As for the minimum height size becoming 330 pix when GUI switched in vertical
position, would that be an issue? I mean, it's not like that would extend the 
minimum
requirements for monitor resolution anyway, right? Ha ha ha...

Original comment by benoist....@gmail.com on 6 Mar 2009 at 10:11

GoogleCodeExporter commented 8 years ago 
Just curious, after 2.0 (the distant future!) will the 320x200 minimum still be 
enforced?
As for reorganizing GUI, it seems that if it is ever undertaken, the best way 
would
be to separate the GUI layer from the image in some way, so that you could draw 
it
using some GUI library, have it fully skinnable, or dragable, floating or 
whatever.
Since tampering with it is a huge task anyway, it would prolly not pay off to 
'hack'
the GUI into vertical arrangement without first making it more edit-friendly, or
standardized, or whatever is the proper term. Perhaps all the GUI feature 
requests
that have to wait until this revamp could be grouped or tagged somehow.

Original comment by ilija.melentijevic on 6 Mar 2009 at 11:02

GoogleCodeExporter commented 8 years ago 
The 320x200 minimum is enforced by the gp2x port. This handheld console only 
has a
320x200 screen. Sure, it is possible to have an hardware zoom and/or scroll, 
but it
does not sound very practical. 
It would be nice to be more abstract, for example the nintendo DS has smaller
screens, so we could use one of them as the toolbar and the other one for actual
drawing. On the gp2x, we could have a button to switch between "drawing screen" 
and
"menu screen", basically having the menu occupying the whole screen.

The current GUI system is pretty flexible, buttons can be moved anywhere on the
screen, the problem is that the picture management expect the usable screen 
area to
be a rectangle starting at 0,0, and going to the menu start at the bottom, and 
the
zoom splitbar at the right, if they are visible. Changing that would need a 
rewrite
of all the functions. As everything is done with direct SDL memory access, this 
means
many problems to sort out.

A solution would be to use the SDL screenspace for the picture, and some other 
thing
for the menu and windows. But, SDL doesn't offer any practical ways to do that 
: no
multiple windows, no easy integration with another toolkit. And i don't know 
any gui
toolkit with enough portability for all the platforms we are supporting 
(actually,
i'm pretty sure there is none :))

Original comment by pulkoma...@gmail.com on 6 Mar 2009 at 12:37

GoogleCodeExporter commented 8 years ago 
I wrote about the resolution mostly as a reminder for us, because it affects 
more
things. Height 330 seems harmless, but it means that in 800x600, you can't use 
the
"tall pixels" mode (needs 660 height minimum).

In my opinion, a system that handles the 2 layouts (4 if you want all 4 screen 
sides)
would require an exponential amount of code, and in the process we would create 
the
related number of bugs...

> I miss the freely positionable GUI
Nothing we can invent in a few months of work can rival a years-old GUI toolkit.

I fully agree with Ilija there:
> the best way would be to separate the GUI layer from the image in some way
Menus, toolboxes, windows, palette(s), printed text and mouse cursor would be 
in OS
desktop space, native resolution, full colors so we are free from the very
complicated remapping problems.
Only the rectangular "viewports" should be in picture space, apparently 8-bit, 
and
scaled according to zoom levels and pixel ratio. These rectangles would only 
print
part of the image, preview brush, preview lines, XOR lines.

Original comment by yrizoud on 6 Mar 2009 at 2:15

GoogleCodeExporter commented 8 years ago 
If we do that, we will have many portablility problems, most notably the lack 
of 
support for a gui toolkit that supports all of the platforms.
I do agree the idea is nice, however, it will probably mean we left away some 
platforms.
gp2x doesn't have any toolkit library installed by default, meaning we would 
have to 
link one statically to the binary, making it very big. It does not have a 
window 
manager either, so we can't use external windows.
Amiga 68k (and maybe others) SDL implementation lets us access the video memory 
directly. And I mean really directly. Everything runs nice in fullscreen mode 
with 
the current build, but if you launch grafx2 in a window, the graphics are 
corrupted, 
because the window is not linear memory, but some lines spread across the 
screen...

I think one solution could be to switch the screenspace to use 24 bit, that 
would 
mean we have to do a conversion each time we display something, but this 
conversion 
is already done on most platforms whith the current system, as most videocards 
don't 
suport indexed 256colors modes. A 24bit screen means we can have truecolor 
graphics 
for the icons/menus/windows, we can do fun things like 256 colors per layer 
with 
true alpha channel, and maybe some other tricks.
Unfortunately, it also means we have to rework a big part of the code to use 
SDL_BlitRect to convert the pixelformats from 256 colors to 24bit.

The multiwindow layout doesn't seem quite a good idea for me (ie having a 
floating 
window with all the tools, like gimp), it will look like a mess. However, i'm 
all 
for external windows for palette, load/save, and all that stuff. SDL 1.3 may 
help 
there.

Original comment by pulkoma...@gmail.com on 6 Mar 2009 at 8:11

GoogleCodeExporter commented 8 years ago 
I didn't want to (be the first to) sound negative, but I'm aware that changing 
to a
GUI toolkit is a fork.
The end-result UI does not *necessarily* have a mess of floating palettes : my
prefered GUI would occupy a full rectangle (no accidentally clicking in a 
"hole" and
activate a window below), and the icons would be soldered in place (no 
accidental
dragging).

Original comment by yrizoud on 6 Mar 2009 at 11:38

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Latest iterations of flash (esp Flash8) have a nice 'docking' GUI that 
practically
consists of vertical and horizontal screen slices. Adobe kinda watered down the
concept trying to make it fit to all of their apps, but it's still maybe food 
for
thought.

Original comment by ilija.melentijevic on 7 Mar 2009 at 9:50

GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 7 Apr 2009 at 1:02

GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 26 May 2009 at 7:48

GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 2 Sep 2009 at 9:41

GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 15 Sep 2009 at 7:13

GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 15 Jan 2010 at 7:34