About Qucs need a independent dialog

[yodalee]

My desktop resolution is 1366*768, and Help->"About Qucs" shows like this:

The single QMessageBox is not enough for all contributors, we need a independent dialog for this.

[in3otd]

...on my screen it barely fits... I saw this some time ago and I agree it will be better with a different (tabbed ?) format. Didn't really think much about, any nice idea will be welcome (...auto scrolling contributors list anyone 😄 ?)

[yodalee]

Simplest, of course, is a read-only QTextEdit with scrollbar. Use tab widget to separate different categories (main group, translate team, free software contributors) of contributors is another way, but more complicated.
The data is a little out-of-date, but I think this is another issue.

[in3otd]

ok, I can try to do that, unless you already planned to do it...

[guitorri]

Let us try to use the Assignee on the right, so we know if an issue is being already handled by one of us ;)

[in3otd]

agree, I was actually asking since I saw that the Assignee is seldom used... 😁

[nvdl]

Has it already been done. If not, here is the new messagebox.

@yodalee Please check it at your resolution.

Branch: shortcut-keys-and-gui

[guitorri]

@nvdl, just a word of caution. As I understand you are new to git. It is better if you use a separate branch for each independent feature or bug fix. It makes it easy for you to rebase, pull request, revert and for others to review your code. 😉
Your new about dialog looks good to me 👍

[nvdl]

Yes, I am new to git.

To be exact, you mean that to fix this issue, I should have pulled the main branch to my newly created branch. Then do the editing and issue a pull request.

Right?

Would that not create a lot of stale branches in the end?
Or should the branch be deleted after the pull request is complete?

It would be nice if you reply with some git commands.
There are many to dig in. 😋

[guitorri]

Yes, you can put your last commit that modified the about box into a separated branch.

This is how I do in general:

1. git pull github master // update from remote
2. git checkout -b new-feature // branch
3. ... do work
4. git commit -a // write a descriptive commit message
5. git push myFork new-feature // push to my fork the new code
6. ... ask for a pull request from myFort to GitHub/Qucs/master branch
7. after the merge on the remote you receive a notification and can delete your branch.

[in3otd]

thanks @nvdl , actually I had worked on this already, but did not push since I wanted to add also a "what's new" dialog, then got distracted by other things. Will try to push it today or tomorrow, so you can give some feedback.

Regarding git, I am also quite new, I started preparing an additional chapter on how we use git for the Qucs development to put on the Wiki, but again did not push it... I guess I should not try to work on too many things at the same time 😁

[nvdl]

I will add that it is a scrollable messagebox class that can be called from other places as well to show text that will not fit in the screen.
For "What's new" addition, it can be chnaged to a form with some fancy scrolling.
I am always into eye candy. 😆

I agree, there should be some guidelines to get started with this project.
Git can be used in many ways and that depends on how people agree on working with a project.

The way I have been using it is to work with one branch in my fork.
Since, I have yet to fix some issues, I did not create a pull request.

Now, I have to figure out how to handle all the changes that I have made to a single branch; split that to many branches and create pull requests or...

@guitorri has a point in creating a single branch for a single issue; less code to review and merge.

Then comes the issue of personal preferences, I want to add something that may not be needed by others (this is the freedom I am looking for 😉) ; in which case I have to keep a separate branch while still keeping in sync with the main branch for updates and new functional addition.

BTW, how do we handle proposed functionalities? For example, I want to implement something and want to know the interest of others. Any voting mechanism?

[guitorri]

@in3otd when you have the time please update the wiki... I also have some random notes to add. We can put some basic workflows and references to more complete Git tutorials on the web.

@nvdl fast branching is one of the best things about Git. You can always transfer commits across branches with crerry-pick. An interactive rebase allow you to select commits, squash, and resolve conflicts as you go. The gitk tool is also helpful to visualize what is going on. It will take a bit of time till you build a mental picture of how Git works, and how it works best for you...

You can periodically merge master in your personal branch to keep it up to date and with your preferences on top.

IMHO, for small proposals an issue or pull request might be ok. For larger things it is better if you plan it first and then communicate on the qucs-devel mailing list before you start coding. People will give you feedback, or votes. You can create an enhancement proposals on the Wiki if you like.

[in3otd]

@nvdl, just a comment on the "single branch for a single issue; less code to review and merge": this is not always true. Take for example your "Gui related issues": if you create a branch for every single point there, that will mean the reviewer(s) will have to pull a branch from your repository, test the code and merge for every point. If you keep all in one branch, this will be done just once. And since the modifications will likely involve always the same 3 or 4 files, it will not be too difficult for the reviewer to follow the code changes. Of course you should have separate commits for all the points, this will make easier to review and debug the code, if needed.

The assumption here is that a pull request is "a solution to a problem". But the boundaries of the problem are sometimes subjective. E.g. you are bothered just by the "Text disappears after drag starts" and do not plan to work on other GUI issues in the near future? Fine, just make a new branch with your solution and do a pull request for this single change. Do you instead plan to more systematically review and correct all the big and small GUI issues (as you are doing)? Perfect, do a branch for the GUI issues and just do a single pull request for all the points.

Then, while checking the GUI issues you see that the "About" dialog need to be refreshed? Is this still part of the GUI issues? Yes and no. If it is a simple change, you can slip that in, if it is more involved, do a separate branch.

All above IMHO, FWIW, YMMV, etc. of course.

[nvdl]

Nice speech. 👏

I agree about keeping things together as long as the concerned files are smaller in number which is my case.
I think, it is do it and find it scenario.
Let's see how things go with Gitvolution.

Somehow I am relieved that I do not have to sub-branch my GUI branch into many branches. 👍

But for other changes, I will branch out and send pull requests.