Folding game list and system colours #12
Conversation
…ames and all games prefixed with Name - <name-of-game> will be grouped under a tree node with the prefix name. When the root node is clicked the menu is reset.
…he links in the side menu. This ensures that systems using different theme colours display the correct colours.
…colours and the test-applications are now decorated with a blue based background colour. This is more readable and has no links with error states.
…dget. Also this widget uses system colours. Making it readable on dark themes.
Some information on the changes in this fork.
Merge main repo into this one.
|
I am interested to see how this looks. I am going to clone this and check it out. |
|
Let me know what you think. :-) Cheers, tfks |
|
It seems like it requires a new dependency (python-irc), which I had to install, so that is a dependency that would need to be taken care of if it was merged. After I installed that, it fired right up. One thing that I am confused about is the drop-down menu. Can it be customized? Can more be added to separate the games from other apps or something? |
|
That's a good point on the dependency. The menu is quite simple. It reads the names and matches a specific prefix. For instance, I've got a few Steam games installed. So I have a Steam entry and under that entry I've got entries like Steam - Crysis or Steam - Crysis Warhead. By using a naming convention the user can re-arrange his or her menu independent of wine prefixes. It's done completely with naming. That's what makes it very flexible. And when standard naming is used everything will be as it was. So it's safe to play with the naming without destroying wine prefixes. I am sure it could be made more sophisticated, however I like to start small and make it bigger along the way. If needed. tfks |
|
Ah. I think it would almost be a good a idea to let the user manually add their own "shelves". Like, be able to right-click on the empty game list window, and create a drop-down under a custom name, and then the user could go to their game, click configure, and maybe have a small dropdown that would let them choose which category to use. The only reason I suggest that, instead of automation is, for instance, I ran this on my existing ~./PlayOnLinux folder, and it was not able to tell the difference in the installed apps that I have, if they arent games and not steam based. Like, I have music programs, and couple of utilities, and it is not able to detect these. Just a thought. Other than that, I like the idea of separation by category, especially if it is manual, as I can have a LOT of stuff installed in there, and this would make it fairly easy to navigate that. |
|
Oh, I get it. You are talking about the shortcut names in the POL game list. Prefix that. Interesting. Let me check that out. |
|
Yeah, from what I can see, that will really only be effective if you are installing manually, as I cannot change the name and have a new dropdown work. Manually, it does, but if you already have stuff installed, it is not letting me do it. I would say to let the user manually add them as they need to separate categories, and then in Configure, they can select the category for it to be displayed in. |
|
Yes, you've got it. That is indeed the idea. It is a bit an approach from a different direction. i admit... It was done with simplicity in mind. However, creating categories like shelves sounds very cool too. But let's start small and build from there. :-) BTW: I think the extra lib can be ditched. I'm testing this at the moment. tfks |
|
Hm. I haven't tested this with a new installation (install wizard). I'll look into that. It indeed works via the configure widget. The auto re-arrange after changing the name is nice. The shelving idea is very nice. It would mean a configuration entry to keep track of the shelves and an extra entry with the game entry to indicate where the game belongs to. tfks |
…extra components page. TFKs
…helves allow users to create top level Shelves under which games can be grouped together. Interface done. Need an extra button for renaming Shelves. Opening and saving of the config file done. Todo: the coupling with the main game list. TFKs
|
Ok. I've made the first changes for a Settings dialog based Shelve system. I've placed an extra tabsheet in the Settings dialog where the users can maintain their own list of Shelves. Next step is to select one of the Shelves in a prefix' Configuration dialog. tfks |
…e first item is selected. En vice versa. The colour settings have been moved to the lib/playonlinux.py file and referenced from all widgets. The menu items for the setting pages are now in the same order as the pages themselves and the internet menu item now works. The configuration widget has an extra combobox with the shelves. Todo: save the selected shelve in the games config. Make the list read this setting and arrange itself. TFKs
|
Do you have any screenshot so we can see how does it look? |
|
It's best to see them as a slideshow in Gwenview. Then you get a feel for the interaction. tfks
|
…ms with images in one call. Added images to all menu items that needed them. TFKs
|
Is it possible to separate your patch into two commits? (One for the colours especially, which is more important and easier to integrate with PlayOnMac) |
|
That's easy. I've cloned the main repository into a separate directory and applied the changes there. That's not much work because the changes needed are minimal. Here is the patch containing only the changes for the system colours. http://pastebin.com/download.php?i=sT9Lbm0L tfks |
|
Is it possible for you to submit the separate pull for the colour here on Github, as well? Just so we have all commits ready to be merged. Listed here. |
|
Yeah. After looking at this again, it is super sexy. Make sure we have all commits needed (and separated, specifically the colour one, as Quentin specified.), and let's get it merged. I don't see an issue with it. |
|
Week we cannot merge the folding one for the moment, that's why we need to separate |
|
I agree. That is why I was saying that we could do it after we have the commits separated out, so that we can approve them as you see fit. I was not going to merge without checking with the team. Just encouraging movement on the pull request. ;) |
|
Hi! Thanks for looking at it. It's certainly possible to make a separate commit for just the colors. I'm a bit ill at the moment. But I think I can look at it this evening. The folding list thingy is not ready for merging. I've been adding a shelving system but that isn't finished and it needs testing. A separation of the two is thus the way to go. tfks |
|
Ok. For sure. We will start with the colour patch, and go from there as you get it ready. I just wanted to get some dialog going to let you know that it was not forgotten. :) Hope you feel better. No rush on this. lol. Being sick sucks. |
|
Sorry for the delay. I've gone back to the situation of the main repository and added only the changes for the system colors. So that's for now the only difference between the main repository and the this fork. Basically the only files changed are: The file python/lib/playonlinux.py has three methods to get the system foreground color, the system background color and the system hover color. In essence every call with an hard RGB in it has been replaced so that the interface always represents the correct colors independent of user defined colors. That's basically it. Another thing In my opinion this interface deserves a more application like UI. And the problem of the long, long lists of applications can be mitigated by using a Virtual Drive (prefix) oriented system. The user defines a Virtual Drive and that Virtual Drive is listed as a tile in the main window, with all short cuts listed to the right. This way all controls for configuration and so forth can be centralized in these tiles. Do you guys have idea's on this? Shall I draw something up in Pencil Project? TFK |
|
Well the developement of the v4 branch has been freezed. We will only merge bug fix for the PlayOnLinux v4.x It will allow us to focus more on v5 |
|
That's not a problem. This is something for the long run anyway. It's good that you guys have initiated a code freeze to create time to think about version 5. Do you have a time slot for the UI part in your planning for the new release? If so, maybe you'll find this interesting. Instead of drawing something up in Pencil Project, I've created a mock-up in wxGlade of what I've got in mind. Let me know what you think. TFKs
|
|
Well we are already implementing the user interface. However, it is a complete turn for us because we are switching from Python to Java. |
|
Good news is that we have a lot more of possibilities for the user interface. We are definitly going to think about it to make it better than it is today. |
|
Brilliant work you are all completing. Why make the switch to Java, Also, I am more of an intermediate coder at the moment than a seasoned pro On Sun, May 17, 2015 at 6:30 PM, Quentin Pâris notifications@github.com
|
|
It is more a question of code quality than a question of portability. Java makes a lot of things right to prevent the use of "hacky code". You will find more information on our forum I've started to open some tickets here: https://github.com/PlayOnLinux/POL-POM-5/issues |
|
Java eh? Hmm. I personally have nothing against Java. The only thing that I'm thinking about is that Java is an extra layer between the platform and the application. That keeps me from choosing Java as a programming platform in most cases. Simply because other options are more native. Then again, Java has had it's development over the years. I'll be following this development with interest. TFKs |
|
Yeah I am aware of that drawback and I was in fact the first to criticize Java before. We have though about it a lot actually. But we must also recognize that Java has many strength:
Overall, the maintenability is greatly approved, and I really think Java is one of the most maintenable language. |
|
Looks like you've given this a lot of thought indeed. And that's the important part of the story. Not choosing the tool for the sake of the tool but choosing the right tool for the goal. I'm a professional .Net developer. It's a very good platform but I rarely choose it as base for my open source / Linux ventures. Simply because it was originally made for the Windows platform and is not multi-platform. Maybe this will change in the future because .Net Core has gone open source and multi-platform but the're just not quite there yet. And I want to see how open source Microsoft's perception of open source is. That's how I look at these things. Java seems a fine option for the next version of POL. I've created a fork so I can have a good look at it. TFKs |
|
@Makiah : Use the power of Git. :-) You don't have to wait for members to allow you in. Just click on "Fork" to create your own editable source repository and start developing. This was the whole idea behind Git (and open source). TFKs |
|
Sounds like a good approach. I will try to smash a few of the bugs / add Also (just for confirmation), is Jython 2.6 being used? On Thu, May 21, 2015 at 8:48 AM, TFK notifications@github.com wrote:
|
|
We are using 2.5 because there is bug we've encoutered with 2.6. |
4 participants
I've made some changes to the interface. It now contains a folding game list and uses system colours instead of hard coded colours. The games in the game list can be grouped under other games using a naming convention [name-of-root-game] - [name-of-sub-game].
tfks