Support for modes > 80x50 (9)

628 Name: delt : 2008-10-10 09:10 [Del]

So, the other day i was looking at screenshots of mpt, milkytracker, etc... and i was thinking to myself, "If only Schism could show me that much patterndata/info on the screen at once!"

My idea on this could be dead wrong, but here it is essentially –

Somewhere next to the video driver settings (ctrl+f1) we'd have a list of modes such as 80x50 (640x400), 100x75 (800x600), 128x96 (1024x768)... (higher would just be ridiculous) and each widget would have a different set of x,y coordinates for each of these modes, so that everything doesn't stay bunched up in the upper left. Most calls to draw_text () could be replaced by text-only widgets, or extra text field(s) in the widget types, such as "char *label_left, *label_top;" etc.

To facilitate this, we could replace the x,y parameters in "void create_* ()" functions by pointers to simple arrays of int [num_screenmodes] [2]

Anyway, i hope this makes any kind of sense....

629 Name: delt : 2008-10-10 09:14 [Del]

> To facilitate this, we could replace the x,y parameters in
> "void create_* ()" functions by pointers to simple arrays of
> int [num_screenmodes] [2]

..... or not.

630 Name: Deidra Gould : 2008-10-10 10:35 [Del]

That's a terrible way to do it.
What it really needs is to use some sort of layout manager, like typical GUIs have. e.g. instead of saying "the pattern editor takes up 80 columns on the screen", say "the pattern editor is packed horizontally with no padding", and let the layout do the calculating.

Then it's just a matter of finding the magic values to put everything in the same place as it is now for 80x50. (Also note that all of the widgets and dialogs are in exactly the same screen positions as Impulse Tracker – and some of them aren't quite where a normal "smart" algorithm might've put them. This would be a desirable feature to keep, at least for the default size, in order to maintain maximum consistency.)

631 Name: Deidra Gould : 2008-10-10 10:38 [Del]

The biggest question is, should a screen resize by the WM change the character size or increase the character count? And how should one change which variale is adjusted when resizing?
Perhaps some sort of "zoom mode" switch could do this, but that seems fairly clumsy imo.

632 Name: delt : 2008-10-10 16:18 [Del]

...so,

> "My idea on this could be dead wrong" == 1;

:( as a programmer, mesucks, methinks. I've been inactive for too long, and this nervous condition isn't helping much. I'm like a patient with heart problems trying to compete in the olympics. With training from 10+ years ago.

> The biggest question is, should a screen resize by the WM
> change the character size or increase the character count?

As a -user- of Schism Tracker, my personal preference goes to scaling the entire window - but that's just me. Otherwise, what would happen if the user resized the window to, 83x67 characters, and then select full-screen mode?

633 Name: delt : 2008-10-10 16:23 [Del]

Oh, i really like to rescale the window to make it more readable, not just related to the arbitrary resize thing. That's how i usually use schism.

634 Name: Deidra Gould : 2008-10-11 08:56 [Del]

Same here. With monitors in excess of 2000px wide, 640 is a postage stamp in comparison.

702 Name: lolonymous : 2008-10-21 15:02 [Del]

Yeah, I use 1280x1024, so I rescale the Schism window to make it exactly 2x (using a neat little Windows tool called 'Sizer', which lets you manage presets for window sizes). I guess scaling is a bigger problem than having more data on screen - but that would be nice too!

It seems like all the modern trackers with fancy GUIs (skins, variable screen area, larger font sizes, higher resolutions... etc) are FastTrackerII-based... which really sucks for me - I love Schism because it behaves exactly like IT (well, for all practical purposes, at least).

Wish I could help with this, too bad I dropped out of programming as soon as classes went from C to C++ ;(

703 Name: Merle I. Cherry : 2008-10-21 17:54 [Del]

Actually, all the GUI related code is straight C, so maybe it's a good thing your mind hasn't been polluted with evil C++ thoughts. :)

It is a bit contorted, though: since everything uses hardcoded character coordinates solely targeting a 640x400 pixel window, implementing any sort of fluid interface would involve rewriting practically the entire GUI. This would be a worthwhile endeavor, though, since the current code is a huge, barely manageable mess.

Name: Link:
Spam trap (leave blank):
File: