Convert PurpleRequestField into a GObject

Review Request #2320 — Created March 6, 2023 and submitted

Information

pidgin/pidgin
default

Reviewers

This is just a straight conversion with not much attempt to make things nice.

Also, this leaves PurpleRequestField as a multi-type object, but derivable, so we can change to a bunch of subclasses after.

Compiled and opened Request Fields from Demo protocol.

Summary ID
Convert PurpleRequestField into a GObject
82606458336e0fa9ab4132b91629089465f641b4
grim
  1. 
      
  2. If we go the subclass route, it looks like the shared properties would be

    • group
    • id
    • label
    • type_hint // If necessary?
    • visible
    • required
    • sensitive
    • uidata // presumable being removed soon (tm)
    • tooltip

    And then it looks like the validator stuff could be moved to a virtual function.

    I'm not sure we want a ton of files for this, but maybe if we put them in a subdirectory?

    That said, I do think subclasses is probably the way to go long term.

    1. I was leaning that way as well, but it looks like that will balloon this review a bit, as everything needs to be made private once the main type is derivable. Just doing the prep work to do the first one (string) gets me:

      ❯ hg di --stat
       libpurple/purplerequestfield.c |  723 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------------
       libpurple/purplerequestfield.h |   13 ++-
       2 files changed, 540 insertions(+), 196 deletions(-)
      

      and that's not even with putting it into separate files.

      What I think I'll do is make everything private on this review request, and then do the subclasses separately.

    2. Yeah the make private here then separate sounds like a good idea.

  3. 
      
QuLogic
QuLogic
QuLogic
grim
  1. Ship It!
  2. Great work, thanks!!

  3. 
      
grim
Review request changed
Status:
Completed