Welcome, Guest. Please login or register.
Did you miss your activation email?
October 19, 2017, 10:20:06 PM

Login with username, password and session length
Search:     Advanced search
* Home Help Search Calendar Links Login Register
+  Machsupport Forum
|-+  Mach Discussion
| |-+  Mach Screens
| | |-+  Works in progress
| | | |-+  An unfinished screen set - "Mach Blue"
Pages: 1 2 3 4 5 6 7 8 9 10 »   Go Down
Print
Author Topic: An unfinished screen set - "Mach Blue"  (Read 97217 times)
0 Members and 1 Guest are viewing this topic.
santiniuk
Global Moderator
*
Offline Offline

Posts: 79



View Profile
« on: April 09, 2006, 06:08:30 PM »

Hi,

After seeing Benny's exotic screensets I thought I'd have a bash at making one. Well it was more of a joint effort with Mr Bean and something to do late at night...

Firstly I was learning Screen 4 and secondly I have no artistic talent.

But more dissapointingly I think our method  creating the screen is wrong. The buttons are all individual graphics. I have a decent PC so have not noticed any speed problem but I see the later screens appearing have one graphic with defined 'hotspots'.

Is this the new way to go ?

I have discovered some of the bugs and limitations of screen4 on the way and hope to see these fixed soon. i.e LED states not correct on loading.

The attachement is for a 1024*768 screen although the bottom section would need to change as the actual graphic is larger than this and I forgot about the task bar and title bar  Grin

I call this screen Mach Blue..... Because...... It's Blue........

Forgot to say it was work in progress but is now about to be abandoned......


* MachBlue.jpg (311.03 KB, 1050x847 - viewed 6628 times.)
« Last Edit: April 10, 2006, 09:39:11 AM by santiniuk » Logged
ynneb
Guest
« Reply #1 on: April 09, 2006, 06:28:50 PM »

You idiot Smiley Why would you abandon this, its fantastic.

Funny though, I have thought to abandon my screen because of poor download numbers.

I would strongly encourage you to continue with your develpoment. I suspect it may be more accepted than my screen.

Keep up the fantastic work.
Logged
Brian Barker
Administrator
*
Offline Offline

Posts: 3,532



View Profile
« Reply #2 on: April 09, 2006, 07:04:14 PM »

So Benny are you going to help him finish it Smiley ...

IF you guys need any VB send it to me and I will do it when I have time.
Logged

Fixing problems one post at a time Wink

www.newfangledsolutions.com
www.machsupport.com
ynneb
Guest
« Reply #3 on: April 09, 2006, 07:23:56 PM »

Quote
So Benny are you going to help him finish it ?
I will HELP him, but I wont finish it for him. This is his design and he needs to get full credit for it.

Santini, The only reason I do hotspots over one BMP is because, as you will already know, it is very tricky to get the BMPs to appear over each other correctly.
It also enables you to have irregular shapes for buttons instead of only rectangular buttons.  The other advantage is that its easier for the computer to render one big bmp than 30 smaller individual ones. I dont know if you noticed how quick my screens swap pages.
That been said, I suggest you use the method that works best for you.  There is no work in taking a screen capture of your current work in mach and then using the one BMP and putting hotspots over it.

You will be in very big trouble with me if you dont complete this screen set.


Art has noticed there are still issues that need fixing up with screen 4. I dont know how long it will take to correct these issues, and aslo add the other options i have requested. Even so, dont adandon this project, keep working on it untill you are happy with the results.
Logged
sshneider
Global Moderator
*
Offline Offline

Posts: 394




View Profile
« Reply #4 on: April 10, 2006, 12:03:15 AM »

Sorry to jump in and change the subject but,

Benny I wouldn't be bummed out re: low download numbers.  It's a BETA.  A Ton of ppl don't want anything to do with Betas because, by their nature they are problematic and require R&D to get to a full release.  I'm sure I'm not telling you anything you don't already know. 

Just keep in mind that for every "Maestro of Mach" there are 20 of us that are struggling to understand how to get our motors turning and what the heck backlash is. 

Personally, I think your screen set is cool (I did download and install it) and I also like the MachBlue set that Santini posted.  But if it's not a final tested release, it's like sitting inside a concept car with no engine- Looks cool, it rolls & steers, but it's not going to get you anywhere fast.  IMHO, this is the reason more have not tried it.

Sid
Logged
santiniuk
Global Moderator
*
Offline Offline

Posts: 79



View Profile
« Reply #5 on: April 10, 2006, 06:09:06 AM »

Hey Benny,

I have to agree with Sid, you cannot call it a day yet. Your screen postings were the motivation behind my attempt.

I'm not sure why your not getting the feedback deserved on the latest screenset. It looks damn impressive and combines a lot of functions.

Hang on in....

In fact it wasn't until I examined the construction of your set that I noticed the one image background trick. Quite a nifty idea ! and seems to work well with the button animations etc. Actually as this is my first attempt with screen designer I now understand the various posts that you have made requiring changes and additions to the designer. Oh bring on Z levels !!! and that almighty cure to the white line below text boxes....
Keep banging Art's door on this....

The reason for my original post was really to reflect on the multiple image route I used rather than the one. On reflection as you say there shouldn't be a lot more work to combine these images to a single panel and use the Hotspot method although the plan was to retire MachBlue to a "could of been".

Will speak to my partner in crime Mr Bean and see what can be done....

Cheers
 
Logged
washcomp
Active Member

Offline Offline

Posts: 34



View Profile WWW
« Reply #6 on: April 10, 2006, 07:44:56 AM »

I think we have two choices:
1)  Go with the flow of the screens bundled with MACH and leave tweaking to rugged individualists
2)  Do a bit more work on the Screen Designer interface to allow the average mortal to tackle the screens.

I think there are a couple of structural improvements which Art might consider, which should enhance things:

Assuming that there are maybe 100 common functions (a subset of which sows up as the vast majority of buttons on any MACH screen), there may not be a requirement for each screen set to individually program each button.  As an example, it the "Mist Cool" button always does the same thing (or the "Jog/Step to the right button for that matter), the function could be explicitly called by simply assigning a hot key "key stroke" or input to it, assigning it to a button name (on a tabulation list) and calling it a day.  Basically this would allow someone to pull up the default table of functions within a window in SD and make modifications without going button by button.  It would also allow someone to add a standard button with full default feature set (including VB code) by simply drawing it and referencing the variable on the list.

If each of the button graphics now had a standard name (how many names do you need to define "E-Stop?), then as long as the button sizes for a given function were the same, a single variable could be set defining the directory where the button graphics for that design were kept.  This would allow people to change button cosmetics quickly without overwriting others.

The ability to "break" text from the button as a separate layer would allow buttons to be re-scaled without affecting the text and would allow alternate text (foreign language, or specialty tool for example) on a screen without re-creating button structures.  Call this text a "transparent" bitmap layer.  This would be used in conjunction with the concept of "stacking" bitmaps.  If all the stacked buttons were opaque, and all the text transparent, then only the top text and button could be seen.  Upon assigning a button location, a small table could pop up allowing a choice of which graphic and label could be seen under what condition.  This combines the functionality of a button, its reverse function, an LED, etc. into one spacial unit.  If not invokable, the button could simply turn to the background screen color an "disappear" or alternatively become a universal "greyed out" color.  If START had been hit, then STOP would appear as the only viable option, etc.  There will of course be exceptions where there are more than one choice, but I think these can be addressed easily on an individual basis. 

I feel implementation of the above concepts will allow more intelligent and versatile screens to be quickly constructed (rather then creating more intelligent screen artists :-) . 

Standing back and looking at the user interface reminds me of the discussions about the lines drawn between CAD, CAM and CNC.  On screen designing, you have the physical tool, the interface mechanism between the screen and the physical tool and the GUI interface between the human and the screen.  What I'm proposing is a methodology to make the last section of this command chain more user friendly by allowing the designer of the interface a greater ease in quickly creating more innovative solutions without worrying about the rest of the underlying code structure.

Just a couple of thoughts,
Jeff


Logged
ftissera
Active Member

Offline Offline

Posts: 30



View Profile
« Reply #7 on: April 10, 2006, 05:36:49 PM »

Please Santiniuk don't stop your blue screens set ! to nice !

Hope testing your screens a day  Smiley

Thanks in advance

Francis
Logged
ballendo
Active Member

Offline Offline

Posts: 18


View Profile
« Reply #8 on: April 15, 2006, 05:03:09 AM »

Hello,

Let me add my voice to the others... Do NOT abandon this screenset!

It is one of the finest I've seen. Please finish it...

Ballendo

Hi,

After seeing Benny's exotic screensets I thought I'd have a bash at making one. Well it was more of a joint effort with Mr Bean and something to do late at night...

Firstly I was learning Screen 4 and secondly I have no artistic talent.

But more dissapointingly I think our method  creating the screen is wrong. The buttons are all individual graphics. I have a decent PC so have not noticed any speed problem but I see the later screens appearing have one graphic with defined 'hotspots'.

Is this the new way to go ?

I have discovered some of the bugs and limitations of screen4 on the way and hope to see these fixed soon. i.e LED states not correct on loading.

The attachement is for a 1024*768 screen although the bottom section would need to change as the actual graphic is larger than this and I forgot about the task bar and title bar  Grin

I call this screen Mach Blue..... Because...... It's Blue........

Forgot to say it was work in progress but is now about to be abandoned......

Logged
ballendo
Active Member

Offline Offline

Posts: 18


View Profile
« Reply #9 on: April 15, 2006, 05:13:37 AM »

Jeff,

The idea of a database-driven screenset is an interesting and powerful one. It certainly works well in other software...

As for the start/stop idea; I fully agree. We have too many one function buttons eating up screen space. Having said that, you CAN already do as you've suggested with the text. Witness the job/machine button for the toolpath display. I don't know if multiple bitmaps for a single button have been implemented yet, but that's one I'm hoping for... (been away from "modding" M3 for some time; so don't know what's been done compared to what was gonna be done at this point.) The text already IS "separate"; but the underlying button AFAIK must remain the same.

Ballendo

II think there are a couple of structural improvements which Art might consider, which should enhance things:

Assuming that there are maybe 100 common functions (a subset of which sows up as the vast majority of buttons on any MACH screen), there may not be a requirement for each screen set to individually program each button.  As an example, it the "Mist Cool" button always does the same thing (or the "Jog/Step to the right button for that matter), the function could be explicitly called by simply assigning a hot key "key stroke" or input to it, assigning it to a button name (on a tabulation list) and calling it a day.  Basically this would allow someone to pull up the default table of functions within a window in SD and make modifications without going button by button.  It would also allow someone to add a standard button with full default feature set (including VB code) by simply drawing it and referencing the variable on the list.

If each of the button graphics now had a standard name (how many names do you need to define "E-Stop?), then as long as the button sizes for a given function were the same, a single variable could be set defining the directory where the button graphics for that design were kept.  This would allow people to change button cosmetics quickly without overwriting others.

The ability to "break" text from the button as a separate layer would allow buttons to be re-scaled without affecting the text and would allow alternate text (foreign language, or specialty tool for example) on a screen without re-creating button structures.  Call this text a "transparent" bitmap layer.  This would be used in conjunction with the concept of "stacking" bitmaps.  If all the stacked buttons were opaque, and all the text transparent, then only the top text and button could be seen.  Upon assigning a button location, a small table could pop up allowing a choice of which graphic and label could be seen under what condition.  This combines the functionality of a button, its reverse function, an LED, etc. into one spacial unit.  If not invokable, the button could simply turn to the background screen color an "disappear" or alternatively become a universal "greyed out" color.  If START had been hit, then STOP would appear as the only viable option, etc.  There will of course be exceptions where there are more than one choice, but I think these can be addressed easily on an individual basis. 

I feel implementation of the above concepts will allow more intelligent and versatile screens to be quickly constructed (rather then creating more intelligent screen artists :-) . 

Standing back and looking at the user interface reminds me of the discussions about the lines drawn between CAD, CAM and CNC.  On screen designing, you have the physical tool, the interface mechanism between the screen and the physical tool and the GUI interface between the human and the screen.  What I'm proposing is a methodology to make the last section of this command chain more user friendly by allowing the designer of the interface a greater ease in quickly creating more innovative solutions without worrying about the rest of the underlying code structure.

Just a couple of thoughts,
Jeff



Logged
Pages: 1 2 3 4 5 6 7 8 9 10 »   Go Up
Print
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!