News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

[Project] GUI Theme

Started by Max-Max, May 31, 2013, 11:12:48 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Max-Max

Quote from: prissi on November 12, 2013, 02:42:04 PM
Regarding the cutting: In the original proposal there was a cutting indicated by color lines. This is probably the best choice, as this is will work on asymmetric boxes and similar. As such is can go into the general list cutter, maybe just specified cutimage instead of image. Just image a button like the attached (following the recent pak192.comic tool design). The green help line would prevent wrong cutting and would still allow makeobj to generate correct images.
It is still the current proposal. But you want this in small updates, so I do what I can to make this transformation as painless as possible. There WILL be coloured cut lines and with my current patch the very example you bring up can be achieved by using 2 or 3 images (as before, in the current skin-PAK format). I have explained this so many times now. So I ask you this:
Do you really read all my posts?
Do you understand them?
Have you tried my full patch, to see how it works?
Have you looked at the themes I provided in both source and PAK?

You seems to think that this is it, this is the final theme patch, no more development beyond this point. I have said this so many times now, NO it isn't! It is work in progress because you wanted it to be in small updates.
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on November 12, 2013, 03:12:50 PM
Hmm, lets do a recap on what happen here...
- I used the current skin-PAK format, no changes at all. Prissi introduced a new system that broke all previous skin-PAKs.
- I used the indexed colour system for my new system colours. I was told it was stupid and a new RGB system should be used, so I ripped out my working indexed system colours to replace them with the RGB system, that I didn't introduce.
Again, no one complained about these changes, saying that people wouldn't recognise the code after 6 month...

As I wrote, I have not been looking much at code lately, so the "spilling" I mentioned was based on the discussions. Discussions which included a radically different pak format in general.

When it comes to indexed colors vs RGB, indexed colors are a shared resource the GUI can't freely modify to it's own advantage. If the GUI themes are to be able to freely specify their own colors, these colors must be stored somewhere else and a way to get them from there to the screen was needed.

kierongreen

Ok, I guess I'll be the one to raise my head above the parapet then:

Yes there was a vote.
Yes it was above your head because you refused to accept a consensus opinion.
Yes the people who voted read your posts.
No they weren't convinced.

Max-Max

#563
Quote from: kierongreen on November 12, 2013, 08:08:55 PM
Ok, I guess I'll be the one to raise my head above the parapet then:

Yes there was a vote.
Yes it was above your head because you refused to accept a consensus opinion.
I didn't know there was a consensus opinion. As I understood, my solution was accepted by those who actually took the time to read the original code.

Quote from: kierongreen on November 12, 2013, 08:08:55 PM
Yes the people who voted read your posts.
For some reason I have hard time to believe that because I can still see the same arguments based on false facts about my implementation.

Quote from: kierongreen on November 12, 2013, 08:08:55 PM
No they weren't convinced.
Not convinced? So who tried to convince then, since I wasn't invited to explain my code and what to come down the road?
How many has tried my original patch, read the original code and understood where it will lead?

It feels like a trial where I wasn't invited to defend myself... not a democracy.

I'm very close to just walk away from all this, and I guess this is what you all want. But I will cool down a bit and see how I feel about it later...
- My code doesn't have bugs. It develops random features...

Ters

I don't remember the no longer so secret "vote" being about Max-Max's patch, or Max-Max, directly. It was about whether prissi should do the changes to Simutrans he wanted, which would affect (at least parts of) what  Max-Max has been doing or wants to do. In any case, the statements from either side had already been made, and the jury in a sense retreated into a private room to reach their verdict.

Max-Max

So what is going on here? I'm waiting for the trunk merge so I can continue... (if it is possible after the merge).
I'm kind'a losing focus and interest by this waiting...
- My code doesn't have bugs. It develops random features...

prissi

Sorry it took so long. Git is not to easy to let its data go back. It took me a while the get a patch mingw could apply, and also get the binary files right.

Markohs

#567
in simgraph.h there is a new macro defined, PUSH_CLIPRECT . I think we have more than enough macros, in my oppinion it's not a good solution.

The patch is quite big, I'd like to hear Max-Max oppinion on this new code, since I'm quite lost reading it. :)

prissi

PUSH_CLIPRECT was a leftover from the code from Max-Max ... I can remove it.

Most of this patch was around for more than three weeks btw.

Max-Max

Since I wasn't invited to the "secret" meeting I have no idea why Prissi's structured C code was implemented over mine object oriented implementation (don't you think simgraph has enough C functions as it is?).
Can some one please state why Prissi's implementation was chosen over mine?

I'm currently looking at the implementation, but so far I can't see how I can use this code to achieve my goals.
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on November 20, 2013, 12:47:03 AM
Since I wasn't invited to the "secret" meeting I have no idea why Prissi's structured C code was implemented over mine object oriented implementation (don't you think simgraph has enough C functions as it is?).

The secret meeting was just a round of votes and a few comments on the situation. At least the part I was involved in. All the arguments are in this very topic.

Dwachs

First of all, prissi's patch is valid C++ (at least in MSVC terms - g++ complains).
Quote from: Max-Max on November 20, 2013, 12:47:03 AM
Can some one please state why Prissi's implementation was chosen over mine?
Because prissi's implementation was (a) complete and (b) did not mix different things in one patch, of course this is just my personal opinion. Imho your patches above are not complete and mix different changes. Look at these two patches you posted some time ago: First patch: the big theme patch plus some incomplete rgb stuff. Second patch: the rest of the rgb patch. I would not call either of these patch files complete. And they mix different things at the same time.
Parsley, sage, rosemary, and maggikraut.

Max-Max

So no one didn't actually looked at the design, just that it was "incomplete"? The reasons stated here are mostly not true. This is why I always ask the question if my post are read at all. There are a lot of assumptions about how my code work, it seems like no one really had looked at it.

The major problem here is that some of you say, don't submit code out of context.
Other says, don't submit to large patches, better to do small ones.

It is impossible to do both in this project. If the sole reason is that it was "incomplete", why didn't I get the chance to "complete" it? Prissi's code has been submitted without any code review and I haven't seen any one discussing pros and cons with hour different solutions.

Just because code runs through a C++ compiler doesn't make it object oriented. Object oriented design can be applied to many things, not only code. If the reason is that there are very few people that really know object oriented design, just say so and try to learn something instead.

Prissi's code do not use polymorphism. If we are to add more behaviours or dynamically assign different behaviours to the same object, we need to go down and make the object aware of the differences. With polymorphism, the object itself doesn't need to know anything of this. It is easier to manage, maintain and extend.

My goals include the possibility to change behaviours for various objects, dynamically. This isn't possible with Prissi's design (well it is, but it will be a quite cumbersome job to track down all places that needs to be updated). With polymorphism we can just derive from a previous behaviour and add this to the structure with a few lines of code, all in the same place.
- My code doesn't have bugs. It develops random features...

Ters

Object oriented programming is not a goal in itself. In fact, functional programming is apparently the new "One True Path". There is also nothing in simgraph that will benefit from runtime polymorphism, at least not within the scope of a GUI makeover. (It has compile time polymorphism, without much fluff, which is enough for now. Most of the macro hell have to do with a changeable interface, which OOP can't solve.) Furthermore, simgraph is at the very core of the system, and has seen extensive profiling over the years. Non-trivial changes there is too risky or costly. What prissi did didn't affect existing functionality from what I can see. But one of the issues of discord here is that simgraph is being discussed, beyond requests for new functions for drawing special things.

As for the GUI things, I very much agree that it is difficult, perhaps too difficult, to make small changesets that both work and make sense. At work, we would never ever have considered doing stuff comparable to this on trunk. But I am getting more and more worried that if this had been done on it's own branch, so much code beyond the GUI itself would have been changed, that we wouldn't be able to merge it back to trunk.

Max-Max

My original code didn't add much to simgraph. I used the current simgraph functions. The polymorphism isn't about Simgraph, it is behavioural patterns to how GUI elements resize and further down the road collapse.

The RGB colour aspect wasn't me. I wanted to use the existing system to minimize the impact, but no one was even interested in looking at it. Again assumptions was made of how this was implemented and I was told to use the new RGB system instead.

I tried to submit smaller patches, just because it would be easier to merge into the trunk and gradually update the system, but I was told it was out of context.

Anyone working against the trunk will always have an easier solution to implement compared to every one else. But is this a reason to refuse "outside" development that might require a little bit of work?

The current workflow with smaller patches, that are complete implementations is only possible for bug fixes and smaller tweaks. For larger projects this workflow can't be used and as long these criteria are held higher than the purpose, we will never be able to do larger projects.
- My code doesn't have bugs. It develops random features...

Dwachs

From reading your posts that contain the patch files I got the impression that these patch files are snapshots of work-in-progress. This I meant by 'incomplete'. The rgb patch was mixed into the theme patch ('all colours are screwed up') and a second part was in an extra file. Do you expect somebody to commit these patches as they are?

I am out of this discussion, in fact I joined it just for to purpose of moderating between the competing parties here.
Parsley, sage, rosemary, and maggikraut.

Ters

Quote from: Max-Max on November 20, 2013, 07:23:49 PM
My original code didn't add much to simgraph. I used the current simgraph functions. The polymorphism isn't about Simgraph, it is behavioural patterns to how GUI elements resize and further down the road collapse.

Then maybe I misunderstood you when you wrote:

Quote from: Max-Max on November 20, 2013, 12:47:03 AM
[...] Prissi's structured C code was implemented over mine object oriented implementation (don't you think simgraph has enough C functions as it is?).

The GUI itself is already OOP (although perhaps not very good OOP, I haven't looked much at it), and should continue to be so (perhaps even better). However, I'm a pragmatic person, and don't do something just because a book, fourteen speakers at conferences, and one thousand forum posts and blogs advocate it. Because in my limited experience, five-ten years down the road, a book and fourteen speakers (perhaps even some of the previous fourteen), and one thousand forum posts and blogs advocate against it (at least in the form adapted by the majority). It seems that when programmers get a tool, they use it for everything, sometimes leading to less maintainable systems than before. This is what shapes my opinions.

Max-Max

Quote from: Dwachs on November 20, 2013, 08:05:12 PM
From reading your posts that contain the patch files I got the impression that these patch files are snapshots of work-in-progress. This I meant by 'incomplete'.
Yes, it was limited to keep the patch smaller since this was an earlier argument to not look at it. Others has committed work in progress,  code that break functionality or missing files. So I don't understand why I have to submit fully finished patches when you guys don't? I thought the same rules applied to all of us :o

Quote from: Dwachs on November 20, 2013, 08:05:12 PM
The rgb patch was mixed into the theme patch ('all colours are screwed up') and a second part was in an extra file.
I had to because someone else (as in not me) implemented the RGB system and I was told to not use the indexed system and that broke my patch so I had to update it to use the new RGB system to make my patch to work again.

Quote from: Dwachs on November 20, 2013, 08:05:12 PM
Do you expect somebody to commit these patches as they are?
Yes, after checking that it doesn't break anything horribly bad, gives compile errors or make the game unplayable.
If you had applied the patches and tried it out you would have seen that they in fact worked. I need this base platform to get up to speed. As I also mentioned, the remaining issues will be dealt with ASAP and the patches can be made smaller as soon the base platform is in place.

I split the patch into two parts, on your own request, one dealing with colours and one with themes.

Quote from: Dwachs on November 20, 2013, 08:05:12 PM
I am out of this discussion, in fact I joined it just for to purpose of moderating between the competing parties here.
I take this as you never looked at my original code and how it was implemented. I also take this as you never read any of my documents or goal descriptions.
- My code doesn't have bugs. It develops random features...

Max-Max

Quote from: Ters on November 20, 2013, 08:31:40 PM
Then maybe I misunderstood you when you wrote:
"[...] Prissi's structured C code was implemented over mine object oriented implementation (don't you think simgraph has enough C functions as it is?)."
The GUI itself is already OOP (although perhaps not very good OOP, I haven't looked much at it), and should continue to be so (perhaps even better). However, I'm a pragmatic person, and don't do something just because a book, fourteen speakers at conferences, and one thousand forum posts and blogs advocate it. Because in my limited experience, five-ten years down the road, a book and fourteen speakers (perhaps even some of the previous fourteen), and one thousand forum posts and blogs advocate against it (at least in the form adapted by the majority). It seems that when programmers get a tool, they use it for everything, sometimes leading to less maintainable systems than before. This is what shapes my opinions.
I start to suspect that Prissi's and my code are confused. The code in the Trunk is far away from my original code, most of it comes from Prissi. I'm not using OOP just because. I use it when I can benefit from the OOP that C++ has to offer. My design is build up around the fact that a class can be derived and extended without changing the basic interface.

Encapsulation also contributes to a cleaner solution, less vulnerably to changes. An object can easily be replaced with another, or derived without breaking the interface to those using the object.
- My code doesn't have bugs. It develops random features...

prissi

Ok, this is very much stuff together.

Max-Max you used and index to an array of object to get the drawing function. What kind of polymorphism is this? All gui_xyz stuff is based on gui_komponente, so there is already polymophism. Same for vehikel_basis_t and obj_t, and a lot of other stuff. But those are virtual functions, not arrays of objects.

Anyway, programming is about a solution to a problem. Drawing bitmaps is not somethign that needs much derivation, any interface should be in gui_komponente (and indeed there is zeichnen which is a polymorphism).

And the best solution is the most simple solution (whatever simple is ... ) For me it is least changed lines, or least additional classes (since there is already a huge codebase to maintain). Your mileage may vary, and as Ters said, also personal preferences change over time (and of course with the language used).

simgraph is almost exclusively C code, since it was a C-file and got never converted. Some of the macro hell could be indeed solved by default parameter, and cleaning up simgraph is a good idea (although it certainly is better done in another thread than the GUI one).

I just added two functions (and also you added the ellipse one then). My reasoning for doing the stretch display in simgraph: This is also needed for window background, so I could reuse the function even further.

You were offered hints, like doing the cutting automatically (on demand) in makeobj. You insist aparently on doing it in simutrans, just because. Ever considered this best of both worlds? One does not exclude the other; in fact you convinced me way back that nine part button graphics are a good idea.

Max-Max

Quote from: prissi on November 20, 2013, 10:15:18 PM
Ok, this is very much stuff together.

Max-Max you used and index to an array of object to get the drawing function. What kind of polymorphism is this? All gui_xyz stuff is based on gui_komponente, so there is already polymophism. Same for vehikel_basis_t and obj_t, and a lot of other stuff. But those are virtual functions, not arrays of objects.
This statements make me believe that you don't understand the code. It isn't a list of the same object. The list is used to map a theme ID to its assigned behaviour class.

The list is indeed holding the same object type pointer, but if you look carefully this is the pointer to a base class. This base class defines a common interface and has some pure virtual functions, like Display.
No, the polymorphism isn't in the array, it is the objects stored in the array, but since they all share the same base class they can be stored in the same list and used in the same way without the GUI component need to know exactly what derivative of the base class has been assigned for that particular theme ID. In this way we can add new behaviours without any need to update the GUI Component code.

The derived class defines the pure virtual functions different depending on what rule to apply to an element, this is polymorphism. I have showed this class diagram a couple of times now.



So when you get the pointer from the array, it isn't a theme_element_t object it is one of the derived classes, accessed by the common interface in the base class, so they can all be treated the same way, even if they do things different. This is the polymorphism I'm talking about all the time, not the array mapping theme ID to its class.

When It comes to the GUI components, I haven't yet started on this work and to be frank, I'm not sure I want to do it either. If this simple theme class design is making such a fuzz, then a rework of the GUI components would be a nightmare... so I have been scared of there...
- My code doesn't have bugs. It develops random features...

prissi

Yes that is true, the theme objects are polymorph. However, the code does not call the object directly, it just provides an index, which is looked up and then called the object in the theme manager. If indexes are polymorphism, then our definitions differ (which is the case).

My basic critic to this is, that this does not need any polymorphism at all. It just display a bitmap in the end! All my code does is calling "display_stretch_bitmap" and this relatively short routine figures (and its subroutine) figure out all the needed (and possible) stretching on its own (which is not that hard). If I have to choose between a 50 line function and a base class and several derivations, I have to have a very good reason to use the complex solution. And just "because it is OOP" is not enough. Maintaining simutrans is hard enough as it is now.

If you want stretching the component sizes and alignment, then it has to be in gui_komponenete_t (which already had the align function added from your patch).

Max-Max

Quote from: prissi on November 20, 2013, 11:58:17 PM
Yes that is true, the theme objects are polymorph. However, the code does not call the object directly, it just provides an index, which is looked up and then called the object in the theme manager. If indexes are polymorphism, then our definitions differ (which is the case).
I have never claimed that the array is polymorphic! It is you that brings up this subject up all the time. I have no clue where you got this from?

I have explained this before and I will do it again and can only hope that folks are reading it, all of it.

For those who wonder what a theme ID is or a theme element etc.. read this previous description.

A GUI control knows that It should use theme ID x,z and y to draw itself. It doesn't know what images are used in this process, neither does it know how this is drawn in the client area. So it just tells the Theme manager, "hey, I want theme ID x to be drawn in this client rect.".

Now if we back up a bit, when a theme is loaded by the theme manager. The theme-PAK provides the manager with images located on specific indexes (because we can't give them names) and parameters of how these should be drawn. This gives the artist full freedom to decide for himself how various GUI elements are resized, and eventually mipmap levels for a specific control.

So depending on these parameters different classes can be assigned to various GUI elements. In one theme a button, for example, may only be resized horizontally and in another theme both ways (frame). This is why we have a base class and then derive different behaviours from it.

So back to our GUI control again. The theme manager maps the theme ID x in the list and gets the assigned class as its base pointer and calls the virtual function Display(). Now the correct code will be used without any tests at all of what type of rule the artist has assigned the control. It is simple and straight forward.

Since nowhere in this Display process any tests has been made of what rule to apply, everything is done the same way and no one (neither the GUI Control itself or the theme manager) needs to do any special handling. If we want to add more behaviour classes we simply derive it from the base class and add it to the theme load process. Simple as that! No need to update any GUI controls or do any tests on the way.

Back to the theme manager and theme loading again. If several theme IDs share the same image and rule set, there is no need to store them several times, just insert the same object pointer in the theme ID array and they will all reuse the same object and images.

If a theme ID image is missing the theme manager can easily reuse another object as a fall back, in a pre defined fall back scheme. This is not only handy for fall back, but also minimizes the amount of images needed if several GUI elements can share the same resources. This also prevents a theme-PAK to break when we add more and more theme images. For example: We have 4 arrow images for now. But later on we may add more "arrow" images specific for edit box, combobox, scrollbars etc... Maybe the Artist wants to use the same arrow images for everything? He doesn't need to supply the specialised images because the fall back will be to the generic.

Quote from: prissi on November 20, 2013, 11:58:17 PM
My basic critic to this is, that this does not need any polymorphism at all. It just display a bitmap in the end! All my code does is calling "display_stretch_bitmap" and this relatively short routine figures (and its subroutine) figure out all the needed (and possible) stretching on its own (which is not that hard). If I have to choose between a 50 line function and a base class and several derivations, I have to have a very good reason to use the complex solution. And just "because it is OOP" is not enough. Maintaining simutrans is hard enough as it is now.
It is not just drawing, there is more to it as I have explained so many times now. The use of a base class allows us to use a common interface regardless of the end result. This separates the Theme from the physical GUI control allowing the theme to develop without the GUI Controls knowledge or need of know how.

Quote from: prissi on November 20, 2013, 11:58:17 PM
If you want stretching the component sizes and alignment, then it has to be in gui_komponenete_t (which already had the align function added from your patch).
Now, don't confuse theme elements and their theme ID with the GUI Component's aliment to its surrounding GUI Controls. This is two different things and has little to do with themes.

Questions?
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on November 20, 2013, 09:38:36 PM
I start to suspect that Prissi's and my code are confused. The code in the Trunk is far away from my original code, most of it comes from Prissi.

I am not cofusing the code, because I've hardly looked at it. I do however feel confused by some other thing(s) I can't really put my finger on. While I follow the broad outlines of Max-Max's last post, there are some details that I'm worried about. I've brought up those issues earlier.

Dwachs

Quote from: prissi
My basic critic to this is, that this does not need any polymorphism at all. It just display a bitmap in the end! All my code does is calling "display_stretch_bitmap" and this relatively short routine figures (and its subroutine) figure out all the needed (and possible) stretching on its own (which is not that hard). If I have to choose between a 50 line function and a base class and several derivations, I have to have a very good reason to use the complex solution. And just "because it is OOP" is not enough. Maintaining simutrans is hard enough as it is now.
I can only agree with that.

Max-Max, I read your posts and patches. Hence my comments. Your patches were not ready for inclusion imho. As I explained several times, they had unrelated changes in it, adding commented out code etc. This cleanup work is duty of the patch author imho.
Parsley, sage, rosemary, and maggikraut.

Max-Max

Quote from: Dwachs on November 21, 2013, 07:12:57 AM
Max-Max, I read your posts and patches. Hence my comments. Your patches were not ready for inclusion imho. As I explained several times, they had unrelated changes in it, adding commented out code etc. This cleanup work is duty of the patch author imho.
Afaik the only function that was commented out that I brought in again was display_set_base_image_offset() which I announced in this thread before I reinserted it for the simple reason that I used it.

I did remove the makeobj changes.
I did separated the theme and colour changes as good I could.
Everything else is connected and can't produce any working code without another, and working code in a context has been the reason earlier to refuse my code so I really don't know how to submit this and keep it small, in context, working and contributing something new at the same time.
- My code doesn't have bugs. It develops random features...

Max-Max

This isn't the project I once started any more. The goals are more short termed and not in line with my original goals.

I have spent hundreds of hours in this project and got almost nowhere because my code is constantly rewritten in a way that will move away from my goals. At one point I got the comment "But I am not sure how I could do the cherry picking with this.". This shows how the "inner circle" view contributors. We are merely just a library of function they can pick and chose from freely as they wish. If they can't, they implement your idea in their own way, not respecting what you try to accomplish.

I find it quite pointless to contribute if my work isn't respected. I have spent numerous amount of hours explaining how things work and why they are implemented the way they are. Still, old assumptions are used as arguments and this makes me believe that these people don't take the time to read my explanations, less the code. In private messages I have got support for my ideas and even my implementations and I'm very thankful for that, without them I would have given up this long time ago.

I have decided to go underground with this project based on the following.

- Decisions are mostly made on assumptions, not functional code.
- Secret discussions are held behind my back without giving me any chance to validate the "facts".
- There is a small group of people that stands above the "rules". If I do a mistake, there can be a whole thread about it, but if a member in this "inner circle" introduce compiler errors, it goes by unnoticed.
- The "inner circle" doesn't have a structure of adopting the same rules. One group complains about X and when I do X another group complains about Y. It doesn't matter what I do, someone is always complaining and my code is refused.
- It is just not possible to create a major project and make both X and Y happy. This model works fine for bug fixes, refactoring and very small and limited functions.

The "inner circle" really needs to work out a workflow that can handle larger projects without internal conflicts in the way a patch should be submitted, what to review and how much can be rewritten without the authors permission. Until then I fear that developers will come and go away...

With risk that the trunk will diff to much from my project when I eventually post my "final" implementation, there might just be to much work involved to implement it. I tried to avoid this by posting smaller patches, but this wasn't accepted by group X of the reason "it is out of context". I think I have given plenty of chances to do this as painless as possible, but this hasn't been accepted, so one big mega-complete-all-patch is the only thing left to do now. I will post some screen shots and keep updates of how I progress but I can't guarantee that any of it will be implemented. That decision isn't in my hands...

I might post spin-off effects from my project as small isolated patches along the way.

So again, for those that have supported me, thank you but I will follow one of the early advices to just make this in "secret".
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on November 25, 2013, 09:32:07 PM
The "inner circle" really needs to work out a workflow that can handle larger projects without internal conflicts in the way a patch should be submitted, what to review and how much can be rewritten without the authors permission. Until then I fear that developers will come and go away...
That's the biggest problem with Simutrans as a project. The "inner circle" apparently, and at least partly admitted, doesn't have the ability (time, skill or whatever) to deal with large, or even medium sized, projects by non-inner circlers.

Quote from: Max-Max on November 25, 2013, 09:32:07 PM
- Decisions are mostly made on assumptions, not functional code.
I can understand you on that one, despite being at least somewhat guilty myself.

Quote from: Max-Max on November 25, 2013, 09:32:07 PM
- Secret discussions are held behind my back without giving me any chance to validate the "facts".
You can't validate any facts about how we feel about you and where this was heading, or how we feel about how we feel about you and where this was heading.

Quote from: Max-Max on November 25, 2013, 09:32:07 PM
- There is a small group of people that stands above the "rules". If I do a mistake, there can be a whole thread about it, but if a member in this "inner circle" introduce compiler errors, it goes by unnoticed.
Other people's errors don't go unnoticed. They get fixed. If they don't get fixed, then we've concluded that they aren't errors. Sometimes it may take a while to find the right fix that works on an platforms and compilers, and for the person responsilble to have some spare time with a computer.

Quote from: Max-Max on November 25, 2013, 09:32:07 PM
- It is just not possible to create a major project and make both X and Y happy.
That's the curse of every software project. Normally, you have a boss selecting one solution. Simutrans tends to usually do both what X and Y wants (for small things usually), with all the extra maintenance cost that implies, or neither (for big things).

Markohs

#588
Quote from: Max-Max on November 25, 2013, 09:32:07 PM
... so one big mega-complete-all-patch is the only thing left to do now.

I think you should have started doing this long time ago, seeing how things are evolving.

The best defense for ideas is implemented, working, code, with features not present already in the game. And mostly, when you are facing so much difficulties getting your ideas accepted.

Implement it, make if functional so we developers can't understand why don't we have that already in our code, and working. Show how your code can do things that prissi's and the community current projected patch can't do, or can do way better. And don't forget about performance, it has to be at least as fast as prissi's code.

Whatever the output of this comes, the community will get better, because you either prove prissi and we the rest of developers by extension were right, or we get your project implemented and included in the game.

Good luck, I really hope you are successful. ;)

kierongreen

QuoteI will post some screen shots and keep updates of how I progress but I can't guarantee that any of it will be implemented.
Indeed - I hope you are able to post really impressive screenshots :)

QuoteSecret discussions are held behind my back without giving me any chance to validate the "facts".
Arguments were made, facts were given, given again, and given again once more. You appeared to not accept anyone disagreeing with you, insisting that anyone who did was a poor coder and didn't understand what you were doing. Try to understand how this might appear to people that have worked with the simutrans code for the best part of a decade. Concluding the discussion in private allowed people to freely express their opinions as to a way forward which would hopefully not caused to much offence. Obviously in the circumstances this is nigh on impossible, but we tried our best.


While you might feel the code in simutrans now differs greatly from that you first submitted please remember that we wouldn't have made this progress without your input. It is very much appreciated, and I hope that you do find time to work on other areas of simutrans maybe as well as the gui as a different set of eyes sometimes does improve the game by leaps and bounds. I do sincerely hope that further development by you adds great features. However by the same token I wouldn't want you to waste time merely refactoring existing code as unless there are noticeable improvements for players I fear it unlikely a patch would be incorporated.

Max-Max

Quote from: kierongreen on November 25, 2013, 11:32:14 PM
Arguments were made, facts were given, given again, and given again once more. You appeared to not accept anyone disagreeing with you, insisting that anyone who did was a poor coder and didn't understand what you were doing.
Too my understanding there was never an agreement on what "version" to implement. I constantly had to correct false assumptions and based on the arguments I saw, I could only come to the conclusion that the code wasn't understood since I got the answer that my post was read and code was reviewed.

My code was also judged from the assumption that it was "finished". I said several times it wasn't, it was a smaller update to keep trunk in synch, as I had seen you guys do it before me. The best would have been to just admit that we can't handle partial progress of a large project and wait until I finished the whole project. The current state of the Trunk goes down a completely different path and keeping the trunk in synch with my local copy is near impossible now.
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on November 27, 2013, 01:06:56 PM
The current state of the Trunk goes down a completely different path and keeping the trunk in synch with my local copy is near impossible now.

Ironically, Simutrans has always been criticized for not doing big changes since it would break all the patches under development. But your big GUI project, in combination with the half-height patch, meant that we for once have started doing big changes that have long been postponed.

Quote from: Max-Max on November 27, 2013, 01:06:56 PM
My code was also judged from the assumption that it was "finished". I said several times it wasn't, it was a smaller update to keep trunk in synch, as I had seen you guys do it before me. The best would have been to just admit that we can't handle partial progress of a large project and wait until I finished the whole project.

I think your patches was judged as finished because only finished patches are accepted. The problem is that you need to 100% complete a small feature, that might be part of something bigger, but that works on its own. (Judging from you comments, you seem to jump from feature to feature. I don't know if you do the same with the coding.) More seasoned Simutrans developers may get away with bigger patches in one go, but that's because they have built up the trust to do things right over time. I fear that if you complete all the things you've written about, it will be a patch so big that nobody will take the time to look through it and submit it.

Max-Max

Quote from: Ters on November 27, 2013, 04:22:58 PM
I think your patches was judged as finished because only finished patches are accepted.
If find this very surprising because I wrote this several times and it was said that all my post was read :o

Quote from: Ters on November 27, 2013, 04:22:58 PM
The problem is that you need to 100% complete a small feature, that might be part of something bigger, but that works on its own. (Judging from you comments, you seem to jump from feature to feature. I don't know if you do the same with the coding.)
I have touched the colours because I needed to load system colours. I proposed a colour manager to be developed further down the road. It was never my intention to develop a colour manager at this point, or even by me. I did use the current indexed system but was told it is a bad idea, even without seeing my current implementation, but based on assumptions of what I might have done. I didn't bother to even show what I had done and ripped it out to replace it with the RGB system (that was not implemented by me) and due to the ripple effect it had a lot of updates in the GUI.

I said that I have a candidate for a Canvas class if someone is interested in using it. The format is the same as for the main screen so with some small modifications all graphich functions can operate on it.

The makeobj debug update was because I needed to debug my theme-PAK files.

Just because I participate in a discussion or lay out a proposal, doesn't mean I'm implementing it. I'm pretty much inside the borders of my project.

Quote from: Ters on November 27, 2013, 04:22:58 PM
More seasoned Simutrans developers may get away with bigger patches in one go, but that's because they have built up the trust to do things right over time.
If "trusted" isn't based on working code, but more or less on the coding style (that isn't even documented that well), I can't see how somewhat different ideas can be contributed. The focus seems to be more on code formatting rather than on working code.

Quote from: Ters on November 27, 2013, 04:22:58 PM
I fear that if you complete all the things you've written about, it will be a patch so big that nobody will take the time to look through it and submit it.
So it is pointless to continue this project then? No one will implement it due to its size, nor am I allowed to send small updates of work in progress or check it in myself into the trunk...
- My code doesn't have bugs. It develops random features...

prissi

You patch was judged as a patch. I cannot judge your ideas, I can only judge your code. It was a more complex way to draw images than needed, so I decided to implement a simplier version.

However, the way button images are draw changes absolutely nothing on how the GUI elements are arranged for different sized boxes. In the latter there was no progress for a long time, which is the real show stopper for any themable UI. Well that will most likely be my task for now it seems.

Ters

Quote from: Max-Max on November 27, 2013, 05:05:41 PM
If "trusted" isn't based on working code, but more or less on the coding style (that isn't even documented that well), I can't see how somewhat different ideas can be contributed. The focus seems to be more on code formatting rather than on working code.

Nobody writes 100% working code all the time once the code passes a certain size, even more so when code has to work on multiple platforms with multiple compilers. Products like Jenkins wouldn't exist otherwise. And we assume developers themselves are focused on getting their code to run. So what's important to discuss, is how Simutrans is coded, so that the style converges on something that looks familiar, and the architecture of Simutrans.

Quote from: Max-Max on November 27, 2013, 05:05:41 PM
I did use the current indexed system but was told it is a bad idea, even without seeing my current implementation, but based on assumptions of what I might have done.

You did complain that you felt restricted by the existing special colors and that prissi's feature for finding the nearest special color to a given RGB wasn't what you wanted. As many things depend on the special colors, not just the GUI project, the special colors in simgraph likely won't change anytime soon. So the available options for the new GUI is to either stick to the 256 colors from the 8-bit days, or do something completely new and let the rest of the code follow in time, if possible, until the old special colors can die. Hopefully, any new stuff can avoid mixing up colors that have nothing to do with each other, which I find very confusing with the current arrays in simgraph. My RGB drawing primitives was a low impact change that among other things made it possible to do a new color management system. With real colors, it also seems most right to do color management above fundamental drawing primitives, rather than below them, as doing it below is more limiting in what you can do.