Started by Max-Max, May 31, 2013, 11:12:48 PM
0 Members and 2 Guests are viewing this topic.
Quote from: Dwachs on October 23, 2013, 05:25:08 PMAdding an new skin_besch_t* member to skinverwaltung seems to be still less work than to implement a complete pair of reader / writer for theme-paks.
Quote from: Max-Max on October 23, 2013, 06:07:38 PMI would like to continue to use one skin_besch_t* member for all theme elements because we can treat all gui theme elements as one, not have to know what theme element we are dealing with.
Quote from: prissi on October 23, 2013, 08:42:45 PMI think a list with all stuff in the same object is a monster. With the proposed 9x9 buttons a normal button has 27 (on off disabled) and a color button 9x4=36 images. Add gadgets and arrow buttons, posbuttons, checkboxes, and scrollbars and you have a obj=menu with 93 predefined images. How big a list do you want?
Quote from: prissi on October 23, 2013, 08:42:45 PMOr you can have oneobj=skinname=posbuttonwith three images ...
Quote from: prissi on October 23, 2013, 08:42:45 PMApart from the cleaner approach to find a check box image under skinverwaltung_t::check_button and not under skinverwaltung_t::theme number 54 to 57. If we get rid of the old system that did exactly this, I want to improve the format.
Quote from: prissi on October 23, 2013, 08:42:45 PMThe implementation now has all different objects in one pak, since makeobj can merge paks together (and can also unmerge them easily). That way even a user can exchange certain images, which is also not possible with a monolytic pak.
Quote from: prissi on October 23, 2013, 08:42:45 PMFurthermore, apart from the ground tile code simutrans internally did not used the bild_t members. Those were just added quite late to move the blending of images into the climate ground code. All other code is geared for the image numbers.
Quote from: prissi on October 23, 2013, 08:42:45 PMFor this reason I am not fond of a single skin, and much less of a new mechanism for skins. Keep it simple!
Quote from: prissi on October 23, 2013, 08:42:45 PMAs it goes, either me or Max-Max will waste work, as my way of implemetation is different from his. I.e. I did reuse the skinverwaltung_t, and just added three functions to display_* to display stretched image and ellipse text (the prior was also invented of by Max-Max).
Quote from: prissi on October 24, 2013, 09:42:56 AMYou are convinced to cut the images in Simutrans, Me and also Dwachs adviced agaist. Either adhere to this advice, or we can only agree that we disagree.I cut the images in makeobj, and it took me less than 10 minutes compared to the time it took me to draw them it is nothing. With color lines it would be even easier to cut, but ok, cutting by hand works fine too.
Quote from: prissi on October 24, 2013, 09:42:56 AMThe GUI elements are object oriented, the drawing is not. At a certain points there will be a break, since the OS is not object oriented (apart for Zeta/BeOS). In simutrans all objects themselves call display_xxx functions to do their drawing is a routine called display or zeichnen. Doing different in the GUI from all other objects in the game will add to confusion.
Quote from: prissi on October 24, 2013, 09:42:56 AMI also fail to see how adding another layer will make things more simple: I comparedisplay_stretch_image( gui_theme_t::imagename, place )totheme_manager->display_element( GUI_MAGIC_NUMBER, place );One magic parameter to get the image information, and one location. Only that the second code jumps through some hoops to finally call the first function anyway.
Quote from: prissi on October 24, 2013, 09:42:56 AMAnd stacking clipping works quite well, otherwise the objects on scrollpanes would not clip. They exactly clip their children. But maybe I misunderstood again.
Quote from: prissi on October 24, 2013, 09:42:56 AMThe only critic on my patch so far from Markohs was using too long constants which I shortened. Well I fixed this. I am happy to here some other critice apart from "Well that is boring like the rest" It is ment to be like the rest.But this is going in circles now for so long now. It would nice if there is a decision, since otherwise Max-Max and me are not getting happier.
Quote from: Markohs on October 24, 2013, 07:04:59 PM And to prissi, I'd just suggest another way of handling this. Just give green light to Max-Max to implement this on his way, and when it's finished, if you don't like it, you can allways rollback his changes and change his code. Looking how things are, looks like it's the only realistic option we have now. Seems like prissi and Max-Max getting an agreement is almost impossible.
Quote from: Markohs on October 24, 2013, 07:57:38 PMBut it's not rocket science, it's just code.
Quote from: Markohs on October 24, 2013, 07:04:59 PMI took the time to read your description fully now and I like the design. Just some questions, and not related to if this is included in simutrans or not, because we already know the status of that. Why is text handled not as theme_element_t? Can't it be abstracted as a text_element_t?
Quote from: Markohs on October 24, 2013, 07:04:59 PM I share some of prissi's thoughts respecting zeichnen and virtual calls, but not for the same reasons that him, I think. I just think as I told you before the process you describe in zeichnen should be named "generate_primitives", called on window update, that generates a list of the primitives to draw. Anyway, not having that infrastructure in our project, your solution is good enough, and easily refactorable to the one I propose, in the future. I also understand and share your comments about encapsulation and responsability isolation.
Quote from: Markohs on October 24, 2013, 07:04:59 PM About magic numbers, when I looked at that section of the code, it just understood it's an enumeration of frame classes, I don't really know what's so magical about them. But I might not have understood it fully, I guess. They just look like handlers.
Quote from: Markohs on October 24, 2013, 07:04:59 PM Well, about the code, my personal advise is that if you feel that you want to do this, and it ends not being accepted or too modified, you can allways create your own fork of simutrans in github, and implement it. Once you have it finished and working, maybe the community changes his oppinion. I made a fork the other day to learn how git works, and quite easy to work with, you lose nothing trying.
Quote from: prissi on October 24, 2013, 08:02:46 PMYou say the elements should have rule. Fine, but then these rules (or its positions) need to be changed in gui_frame_t (and within the element) to reflect the actual positions. Or you can click outside a button and still trigger it, which is not what should happen.
Quote from: prissi on October 24, 2013, 08:02:46 PMSo what does the theme manager service provides in the end? Something like a graphic primitive to draw a button with alignment out of nine (or how many) images, and maybe labels. I fail to see the need for another layer.
Quote from: prissi on October 24, 2013, 08:02:46 PM...since with the dominance of Andriods, a Java frontend might became handy anyway.
Quote from: prissi on October 24, 2013, 08:02:46 PMBut as Markohs said, go ahead. I keep the patch in sync, and I may make some other skins for my patch. But those are easily reused for whatever is applied in the end.
Quote from: prissi on October 24, 2013, 08:02:46 PMI would start to separate the buttons into different classes, but that will give quite lots of conflicts, until this is resolved. SO I may go back on the scrolled lists.
Quote from: Max-Max on October 24, 2013, 11:35:23 PMWell, as for now the manager is only dealing with images, not primitives like rectangles or circles. I guess the images would be textures in a design using the GPU later on.But as you pointed out, we don't have such system in place and with this abstraction it wouldn't be too hard to modify the theme manager to work in this way.
Quote from: Dwachs on October 25, 2013, 08:48:24 AMLet me rephrase it to see whether I understood it right. You are proposing an extra layer of theme-elements that handle the display of gui-components frames. The idea behind this is to have a unified way of displaying those frames. This has potential (like buttons that could handle different font sizes ?). But I share prissi's concern: Where this is useful besides using this for the button classes and window frames? I mean, which of the components in gui/components would benefit from the theme layer?
Quote from: Dwachs on October 25, 2013, 08:48:24 AMI agree with you about the need for more gui-components (for instance to take care of texts in a way that switching languages does not make the gui look messy). If this theme stuff is the price to pay to get gui-code refactored, better maintainable, easier exentable (different font size, no absolute pixel coordinates) etc. I am willing to pay it.
Quote from: Dwachs on October 25, 2013, 08:48:24 AMThe way you described it, this theme thing consists of two fairly independent parts: First, the communication gui component <-> theme classes, and second, the communication theme manager <-> pak files/ besch system. Both are controversial, as the need for the theme manager is discussed as well as the structure of a potential new pak/besch/cutting system.My proposal would be the following: Could you provide an updated patch(1) that contains the theme-related code, implements the theme for the gui-components, and does not introduce a new pak/cutting system (ie which uses the existing skinverwaltung stuff for compatibility)? That way we would have a smaller patch to discuss. Maybe you posted such a patch earlier - I did not notice as I did not follow this topic from the very beginning.
Quote from: Dwachs on October 25, 2013, 08:48:24 AMFor development, I suggest to you to use git: mirror the simutrans-project at github: github.com/aburch/simutrans . This tool has a learing curve ofc, but it is so much better in handling branches than svn. I myself started with developing against a checked out svn repository. But then switched to git to develop larger patches (for instance the scripted scenarios).
Quote from: Dwachs on October 25, 2013, 08:48:24 AM(1)A patch that contains that contains exactly one feature: the theme manager and its relation to the gui components. No white-space changes in unrelated files, no debug code for makeobj, no change to resource file etc.
Quote from: Markohs on October 25, 2013, 09:45:47 AM...a atlas.
Quote from: Markohs on October 25, 2013, 09:45:47 AM You are not designing that now, I'm just asking you to have in mind that idea is going there when we can, so try to avoid decisions that go against this idea.
Quote from: prissi on October 26, 2013, 11:12:07 PMNow really. This is just the patch I made earlier, on a personal branch in github (as was suggested in the other thread). Nothing changed there, just instead of a patch file a branch which contains also the graphics.
Quote from: Max-Max on October 27, 2013, 12:12:10 AMif I should fork a new one, from the standard?
Quote from: Dwachs on October 27, 2013, 08:18:09 AMPrissi registered moments ago at github and started his branch very recently
Quote from: Max-Max on October 27, 2013, 11:40:27 AMSo this means we are two developers developing the same thing in parallel, on different implementation paths...