How to change the look of the "messages frame" in the chat window...

How to change the look of the "messages frame" in the chat window...

by Eloy Lafuente (stronk7) -
Number of replies: 21
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi,

I've spent some time trying to do it but I'm not able to see a solution (sure it exists!). The question is...

How to change the appearance (background, message text...) in the "messages frame" of the chat window?

It seems to use the default background and body styles but what if I want to show such window with other look. Not problem with the "list of users" and "text-box" frames. They seem to have the proper classes and ids.

TIA and ciao smile
Average of ratings: -
In reply to Eloy Lafuente (stronk7)

Re: How to change the look of the "messages frame" in the chat window...

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators
Hi Eloy,

Please check the discussion Chat Help. Also, you may find Andy's User script to help with making/debugging themes helpful.

Best wishes from a wood theme fan. smile
In reply to Helen Foster

Re: How to change the look of the "messages frame" in the chat window...

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Helen,

thanks for your answer. Anyway, my problems aren't related with the "list of users" or "text input" frames.

My problem is with the "text display" (upper left) frame. I've used both the "marvellous script" cool and the WebDeveloper Extension (plus the cool "View rendered Source" one) and I'm not able to see any class or id assigned to that frame body, so I'm not able to change its background. sad

Who is missing anything, the frame or me? tongueout

Ciao smile
In reply to Eloy Lafuente (stronk7)

Re: How to change the look of the "messages frame" in the chat window...

by Urs Hunkler -
Picture of Core developers

Hi Eloy,

you aren't missing anything, but the frame which has only one hidden div with an ID which surrounds nothing. And also there is missing someone caring for the bug tracker entry Bug #3376 which covers this point wink Eloy, could you please take over - I offer you my assistance.

Urs

In reply to Urs Hunkler

A similar problem applies to block config pages

by Andrew Walker -
There is a similar (though less significant) problem for the block configuration pages. As far as I can tell they don't have anything in their body signature that differentiates them from other pages.

This has been a problem on a theme I've been working on where the block config pages are picking up an unwanted background image from from another css rule,

body#site-index #page, body#course-view #page {
background: url(pix/bg_right.gif) repeat-y 100% 0; /* image is applied to the block config pages */
}


By default there doesn't seem to be any identifying feature that can be used to create a more specific rule to overide this behaviour on the block config pages. My workaround was to hack the page_id_and_class function in weblib.php to check if the variable blockaction was set to "config" in the query string and if so add an extra class (block-config) to the page.

$class = str_replace(' block-config', '', $class);
if (isset($_GET['blockaction']) && $_GET['blockaction'] == 'config') {
$class .= ' block-config';
}


Not too pretty wink Better solutions are very welcome!

In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

Andrew, every Moodle page has an ID and this ID is unique for this page. You can address the page via this ID. What page ID do those pages have you are working on. You can use the User script to help with making/debugging themes Helen mentioned above to easily find out the page ID and CLASSes.

Urs

PS. Helen, would you like to motivate your colleague Andy to write another script to diplay the attached CSS styles. His info box is so comfortable that I feel quite peeved when I have to change to the "DOM Inspector" to look up the CSS styles wink

In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Urs,

Please note that Andrew Walker is aka Andy! wink No doubt he'll reply to your comment and to your PS. smile

In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Andrew Walker -
Hi Urs,

I think the problem with the block config pages is that they aren't separate pages - it looks like they're just created by data from the query string.

for example if I had an RSS block placed on the homepage (let's say this is http://moodlesite.com/index.php), going to configure the block would take you to

http://moodlesite.com/index.php?some query string to display the config stuff

hence the page would have the id site-index on the body tag. similarly if the RSS block was in a course configuring the block would be done on the page,

http://moodlesite.com/course/view.php?some query string to display the config stuff

so in this case the the config page would have the id course-view on the body tag.

Andy smile

PS. I updated the user script to be able to view computed styles for elements. It's not perfect (for example viewing something like the computed width is probably little help for debugging), but I find it quite helpful. I posted the updated version here - http://www.moddular.org/log/css-inspector - If you're using mozilla please note that it doesn't seem to like shorthand css properties so if you wanted to check the margins of an element you would need to type something like margin-top or margin-bottom instead of the shorthand margin (if you use opera the shorthand is usually fine)

BTW how does the DOM inspector work - the Open DOM Inspector option is always greyed out in my firefox...

PPS. Thanks for the brilliant orangewhite theme - it's been so useful for learning CSS in moodle big grin
In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

Hi Andy,

giving Andrew the tip to use Andy's tool is like carrying coal to Newcastle wink

Thank you very much for your tool and especially the new version. I made some changes to make it meet my needs: For example writing "font1" and getting the whole font shorthand in FF or "box1" and getting all margins and all padding values. They are not programmed as clean as your script but they work for me. Are you interested in seeing it and perhaps doing some code optimizations?

FF's DOM Inspector is really great especially in conjunction with an extension called "Inspect element". You right click on any element on the page and the DOM Inspector shows it in its presentation of page's the document tree. You can then look up the CSS, rendered styles, the JS components and some other helpful information.

Did you install FF with the extended features on? If not the DOM inspector and one other feature are missing.

Good luck
Urs

PS. Into the block config CSS topic I'll investigate later.

PPS. Thank you very much for your nice words about the theme "orangewhite". My aim was to build a good base for Moodle theme work. It seams to work.

In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Andrew Walker -
Hi Urs,

being able to view things like fonts, margins and paddings without the hassle of typing in the long hand versions would be brilliant. i'd love to have a look at the changes. I wrote the script primarily for opera, but I think I'm probably the only person who uses it in opera - so anything that makes it work better for firefox is very welcome smile

> Did you install FF with the extended features on? If not the DOM inspector and one other feature are missing.

Probably not, I'll try to make sure I do that next time I upgrade it smile
In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

Hi Andy,

here it is. I nearly tripled the size wink And I am quite sure that Opera will not like it because I did not care for it with the naming. I did not really implement the CSS short hand definitions but I grouped together the most needed properties while working on CSS design. There is no docu, please look at the code.

But perhaps you will like the "set property:value" for the selected object. You can directly enter CSS changes in your input field and watch how the page changes. I was looking for that possibility for a long time now. With your script the realization became quite easy.

I hope you like it. And perhaps optimise it?
Urs

In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Andrew Walker -
Hi Urs,

That looks great - the set property feature is brilliant! I've had a quick play with it this afternoon, it seems to work in opera too smile

I'll try take a more detailed look though the code this weekend.

Andy
In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Andrew Walker -
Hi Urs,

I've just finished a rewritten version. I tried to clean up my original code by making it less reliant on using closures - as well as being more careful about tidying up event listeners.

Aside from the change in coding style the other major change is the addition of the functionality from your version of the script smile I added your groups of CSS properties as a drop down list, and also included the ability to set a CSS property.


Some other little enhancements...

it automatically converts the rgb(0, 0, 0) colour values reported by mozilla into #000000 style values (I find these easier to read wink)

I think the drag and drop behaviour works a little better

typing the word "empty" into the textbox and pressing enter clears the list of styles currently displayed. shift clicking on an item in this list removes that item

the view/edit CSS panel now also includes the id and class information of the element in its title

it has some tooltips in some places as well as some slightly better CSS.

and maybe a few other things I've forgotten wink

It works in Opera and Firefox/greasemonkey. Please try it out, suggestions are welcome!
In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Andrew Walker -
Oops, I just found a bug - it looks like you can't select text in a page where the script is running. The version attached in this post should fix that smile

In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

Andrew, wow - with your changes your tool becomes more and more wealthy. The popup offers great advantages. I have installed your latest bugfix and found one bug and have two notes concerning the interface:

  • the bug: in my patch I could write "set border-top:1px solid #f00". In your version "border-top:1px solid #f00" does not change the top border line. Do you know why?

  • the interface: Your help text gives a very wealthy introduction for new users. On the other hand it uses lots of screen place. I removed the help text because it's now hard for me to see what I am changing wink Are you one of those lucky wide screen users? I work on a 1024 pixel screen with my browser set to somehow 920 pixel width. What about moving the documentation into the documentation part of the greasemonkey js header? What do you think?

  • the popup: Your "empty" option is very helpful. Looking at an elements CSS I call the property groups with your popup. When the list becomes too long I start typing "empty" to clean it up. This change from mouse to keyboard could be avoided by adding "empty" at the end of the popup. Looking around while searching CSS infos would be much faster using the mouse only. What do you think?

Thank you very much again for your CSS inspector. It has become my favorite tool while working with web design and Moodle Themes.
Urs

In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Andrew Walker -
Thanks Urs,

I *think* I've fixed the bug that stopped CSS properties being set correctly (and in the process found what looks like a redraw bug in opera wink)

The documentation is moved into a comment at the head of the script - this does free up a lot more space smile

I also added an option to empty the property list from the drop down menu.

Finally I added the ability to display some common presentational attributes along with the ids and classes (color, bgcolor, cellpadding, cellspacing etc - look for the presentationAttrsArr array to set which attributes are checked) the display of these items can be toggled on and off by changing the props.displayPresentationalAttrs variable.

thanks again for the really helpful feedback big grin

Andy
In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

Andy, great. Everything I tried works smile))

The presentational attributes are very important for the detective work with Moodle pages - great that your inspector displays them too. CSS work will really speed up with your inspector.

Urs

In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

I stumbled over the same barrier with the module config pages. The page ID of all pages is "#course-mod" and while I worked on the wiki config page it broke the quiz config page sad

Eloy or Martin, can you please have a look at those config pages. The best solution I can think of is to automatically insert a DIV with the ID of the module/block name around the inserted html config page similar to the body ID. This DIV would be inside the #content DIV. Is that possible in weblib.php? Parallel to this posting I opened Bug #4045.

I hope so much you will find an easy way because I am totally stuck in the moment.

Urs

In reply to Urs Hunkler

Re: A similar problem applies to block config pages

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Eloy, Urs, Helen and Andy,

One workaround to set e.g. a background color to the module configuration pages is to set the background-color of the .editing class to the color of your choice (e.g. mycolor)

.editing {background-color: mycolor;}

Of course this will set the background of ALL editing pages to that color. Well, maybe it's OK if you choose a nondescript color and then set - one by one - the background colors of individual modules configuration pages.

See an example for the glossary module configuration attached.

Would that answer your query, Eloy?

Joseph


Attachment moodle.jpg
In reply to Andrew Walker

Re: A similar problem applies to block config pages

by Urs Hunkler -
Picture of Core developers

Martin added IDs to the content part of all edit pages of the modules and blocks. This way you can address the page content via for example:

#chat .the-page-element-to-be-addressed {property:value}

Andy this way you can not directly solve your task to change the body properties. But perhaps you can find a strategy not to attach the background img to the body but to another element? Because I do not know what you want to achieve I only can guess here.

I hope this helps
Urs

In reply to Urs Hunkler

Re: How to change the look of the "messages frame" in the chat window...

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi,

I've worked a bit with (against tongueout) bug 3376. Just waiting for some feedback to continue/kill it.

Ciao smile
In reply to Eloy Lafuente (stronk7)

Re: How to change the look of the "messages frame" in the chat window...

by Urs Hunkler -
Picture of Core developers

Just to give this thread an happy end wink Eloy and I were successful and Eloy closed bug 3376.

Urs