Added screen size-based resize of a GUI

[Aicedosh]

Not happy at all with what I made but I'd like to hear your opinions anyways.

[mrwasp]

How can I safety get this branch to my PC via git commands? (safety means that not destroy my current edition of project)

[Tomivix]

Well, I can see it scaling and I see it's resizable now but for some reason it is quite small by default. So small that once again part of the 15th register isn't fitting inside the window GUI. Something is wrong here so I think you should take another look at it @Aicedosh .

Regarding your question @mrwasp : Just clone Aicedosh/hpa/ViewDev into another, new branch.

[Aicedosh]

Sure, will fix that, but do you have any other solution? I can't really come up with anything other than scaling all components down and I really don't like it

[Tomivix]

Okay, then I'll wait for those fixes before merging. As for actual scaling method I think rescaling all of the components works (although it isn't to fancy...). The only other option I can think of is setting default height for the window quite low, as if we had 720p display (I think most people who would use this software will have a screen with at least such resolution, it isn't designed for mobile users, right?)

[mrwasp]

Maybe put registers to ScrollPanel?

[mrwasp]

Looks good! Nice to see arrow pointing correct cells while processing. @Aicedosh One bug found - when command doesn't read/write data, arrow remains the same as command before (eg. jumps).

[Aicedosh]

"It's not a bug. It's a feature" Arrow always shows last edited registers and cells (I could change it of course)

[mrwasp]

@Aicedosh Ok, if you say so I wonder whether it would be hard to do that color of arrow was dependent command, eg. add-red, sub-blue, etc. It would be easier to see how registers/cells change.

[Aicedosh]

It wouldn't be that hard to implement, I'll try to include that in next update. And should the arrow disappear after executing jump commands?

[mrwasp]

No difference for me, can stay as it is. And another idea: select/mark current proccesing line of code.

[Aicedosh]

Another question: should the orders be included in memory cells panel? I mean what would it look like? Text, numbers matching the orders representation? And what would be the use of that?

[mrwasp]

If we want to be consistent, orders should be saved in memory cells as String in format given in the lecture. AR 1,2 -> "AR 12" LA 13,VAR -> "LA DE 00 00" Spaces separate bytes. While processing memory cell with current order should be set bold. That's the way I see it.

[Aicedosh]

OK, I'll try to implement that as well. However, should there be a gap between vars and orders? I can't imagine having about 200 cells between them

[mrwasp]

Maybe better split it into two collumns.

[Tomivix]

Okay I'm back. Sorry for being MIA for a while. For starters I have a question for you @mrwasp : why are some of your commits from #21 present here as well ? I'm pretty sure this will cause conflicts when I'll try to merge #20 alongside with #21 . Just wondering though...

Also what is this about @Aicedosh ?

should the orders be included in memory cells panel?

I don't really get what you meant here... Why would we have orders in registers/memory section?

[Aicedosh]

@Tomivix I was referring to @mrwasp 's comment: //FIXME GUI - memory cells doesn't store orders.

[Tomivix]

Yeah I know that. But what do you mean by that? Do you want it to work like our lecturer described e.g cell 2048 contains representation of the 1st line from orders section and so on?

[Aicedosh]

Yup, something in that direction

[Tomivix]

Ok, that's pretty commendable. Well, I thought we will be skipping this part but give it a shot if you want. Maybe you know why some of @mrwasp 's commits are in this pull request as well?

[Aicedosh]

Well, to edit what @mrwasp did and fix it I pulled from his repo

[Tomivix]

Yup, that's what see from the commit history. The problem is with 'some commits'. Looks like #21 is still one commit ahead or is it just me?

[Aicedosh]

Yes, my pull request doesn't include @mrwasp 's commit from today. Is it a problem?

[Tomivix]

From your point of view - no, form mine - yes. Since this one commit 61a0721 isn't present here I will have to merge both requests. And when you try to merge commit that already was merged we have a conflict. Dunno why but for some reason GitHub can't process stuff like that...

[Aicedosh]

So should I pull @mrwasp repo into my branch now? Will that work?

[Tomivix]

If you haven't made any edits that overlap with 61a0721 I guess pushing mrwasp/hpa/wasp into Aicedosh/hpa/ViewDev will do the trick. Then I'll just merge this one and close #21.

[Aicedosh]

I think I handled the confilct resolving (not sure though)

[Tomivix]

Seems like your pull request now contains all commits from #21 so everything will work. I'll merge this one and close #21 then, since it would change nothing. Hopefully @mrwasp won't mind.

Anyways thanks for your hard work over the weekend @Aicedosh and @mrwasp !

[mrwasp]

I don't mind, merge it and we go further