Resolution Managment

Moderator: Moderator

parti02
veteran
Posts: 232
Joined: Sat Jun 16, 2007 5:52 pm

Postby parti02 » Thu May 15, 2008 3:27 pm

yes, realy nice.

Gruß
Dirk

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Thu May 15, 2008 4:38 pm

@arj

I have a problem, I cannot add the new general resolution change easily. As you know, the opengl plugin handles 2 different resolutions:

1) is the general resolution
2) is the real screen/opengl resolution (which is stored in the opengl config file) used to scale the resolution in mms

I can easily add multiple resolution handling regarding #2, but the whole plugin assumes the general resolution is a constant :/

What a mess :(
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Thu May 15, 2008 10:40 pm

lorenzodes: damn :( Well I guess it remains sdl only then :)

castorinop: sounds like a good idea. I was actually thinking exactly the same thing when I thought about how much of the code in feature that can be refactored. It would also make it easier to implement old-fart scrolling. I'm with you with the header and that, but I'm not 100% sold on the print list thing. It has already been abstracted. But what needs abstraction is the grid view. See my latest refactoring. Something like that would be nice.

Another thing is that notify and clock code still is size hardcoded. Could you look into fixing those so that they also scale?

Thanks!

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Fri May 16, 2008 12:23 pm

arj wrote:castorinop: sounds like a good idea. I was actually thinking exactly the same thing when I thought about how much of the code in feature that can be refactored. It would also make it easier to implement old-fart scrolling. I'm with you with the header and that, but I'm not 100% sold on the print list thing. It has already been abstracted. But what needs abstraction is the grid view. See my latest refactoring. Something like that would be nice.

What is your opinion how plugin for this ? maybe configurable from theme.conf. this shoud be extends or change the way of handle somethings.
arj wrote:Another thing is that notify and clock code still is size hardcoded. Could you look into fixing those so that they also scale?

how should be show ? tips ? methods ?

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Fri May 16, 2008 1:39 pm

castorinop wrote:
arj wrote:castorinop: sounds like a good idea. I was actually thinking exactly the same thing when I thought about how much of the code in feature that can be refactored. It would also make it easier to implement old-fart scrolling. I'm with you with the header and that, but I'm not 100% sold on the print list thing. It has already been abstracted. But what needs abstraction is the grid view. See my latest refactoring. Something like that would be nice.

What is your opinion how plugin for this ? maybe configurable from theme.conf. this shoud be extends or change the way of handle somethings.


Not sure what the idea of a plugin for this would be. The way I see it, refactoring this out is a way of saying: in the core, we have these functions that will help you write UI easier. Regarding theme.conf, then I agree with magicamun that something could be gained from saying: This is the header font for all, this is the list font for all etc. That way a plugin would only have to say what is specific to that. Such as lyrics in audio.

castorinop wrote:
arj wrote:Another thing is that notify and clock code still is size hardcoded. Could you look into fixing those so that they also scale?

how should be show ? tips ? methods ?


Like this:

Code: Select all

  res_dependant_calc();

  S_ResolutionManagement::get_instance()->register_callback(boost::bind(&Audio::res_dependant_calc, this));
}

void Audio::res_dependant_calc()
{
  header_font = graphics::resolution_dependant_font_wrapper(28, conf);
  ...
}


Then header_font will scale based on resolution. And for height:

screensaver_artist_font_height = graphics::calculate_font_height(screensaver_artist_font, conf);

Take a look at audio, picture, movie or games. They should have been converted to work with this. Mostly you just need to make sure that there's nothing like this around "Vera/28" :-)

User avatar
castorinop
veteran
Posts: 331
Joined: Wed Jun 07, 2006 6:34 pm
Location: Argentina
Contact:

Postby castorinop » Fri May 16, 2008 2:09 pm

arj wrote:
castorinop wrote:
arj wrote:castorinop: sounds like a good idea. I was actually thinking exactly the same thing when I thought about how much of the code in feature that can be refactored. It would also make it easier to implement old-fart scrolling. I'm with you with the header and that, but I'm not 100% sold on the print list thing. It has already been abstracted. But what needs abstraction is the grid view. See my latest refactoring. Something like that would be nice.

What is your opinion how plugin for this ? maybe configurable from theme.conf. this shoud be extends or change the way of handle somethings.

Not sure what the idea of a plugin for this would be. The way I see it, refactoring this out is a way of saying: in the core, we have these functions that will help you write UI easier. Regarding theme.conf, then I agree with magicamun that something could be gained from saying: This is the header font for all, this is the list font for all etc. That way a plugin would only have to say what is specific to that. Such as lyrics in audio.
the idea is if someone wish change de some aspect of mms, she/he can be extends the base plugin, change somethings and magic! new aspect without touch the core.


arj wrote:Like this: ...

i take a look for this...

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Fri May 16, 2008 2:14 pm

Ok. I guess that makes sense.

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Fri May 16, 2008 4:24 pm

arj wrote:lorenzodes: damn :( Well I guess it remains sdl only then :)


Damn, you provoked me. I will find a way, even if that requires rewriting the whole plugin. :twisted:

BTW, wouldn't be more consistant if the switch resolution thingie were among the options? It doesn't belong in the main menu imho.

Also, in the option menu you would be able to:

1) support more resolutions
2) let user know what resolution they're selecting.
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"

User avatar
Uatschitchun
Overlord
Posts: 3189
Joined: Tue Dec 06, 2005 6:55 pm
Location: Germany
Contact:

Postby Uatschitchun » Sat May 17, 2008 6:34 am

lorenzodes wrote:1) support more resolutions

That would even be an advantage for LiveCDs and first-time users beeing able to change resolution without doing config-changes ...

Even nice would be to change from (example) 800x600 windowed to 1680x1050 fullscreen ;)
Lg
Roman

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Sat May 17, 2008 11:06 am

Ok. That might not be such a bad idea. The fullscreen def. needs to be there. I'll do it so that by default it will list all normal resolutions and if alternative is set, it will only lists normal and alternative. The only thing about the fullsceen is that we don't have an apply, so it would be: change fullscreen and then resolution, that might be a little confusing, but should be ok.

Thanks for the feedback guys!

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Sat May 17, 2008 4:29 pm

arj wrote:The only thing about the fullsceen is that we don't have an apply


Yes, we do. A secondary menu that says
"Video output settings have changed.
Discard
Apply"

BTW, it would be ideal if those options were plugin dependant. The opengl plugin has to handle 2 resolution settings (real and virtual) while the dxr3 one might need it to set the correct zoom value, etc.
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Sun May 18, 2008 8:10 pm

Well we don't have a tradition for doing secondary menues in options. So it's kind of non-intuitive. I'm still not 100% clicked in on the idea of bringing it into options because of this little problem.

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Sun May 18, 2008 10:18 pm

arj wrote:Well we don't have a tradition for doing secondary menues in options. So it's kind of non-intuitive. I'm still not 100% clicked in on the idea of bringing it into options because of this little problem.


We do have the tradition of having option fields marked with a [...] thingie that tells user he has to hit ok to bring up more stuff.

The way I see it we can do this 2 ways. Actually, the one I prefer is this:

Video settings
..Screen Size...............800x600 [...]


You bring the cursor on 800x600, hit Ok and you're prompted with a list of screen resolutions via the secondary menu, which, as you know, supports Ok/Back buttons which, coincidentally, match the Confirm/Discard actions we need :)
"I’m not frightened of dying, anytime will do, I don’t mind. Why should I be frightened of dying? There’s no reason for it, you gotta go sometime"


Return to “feature requests”

Who is online

Users browsing this forum: No registered users and 1 guest